Re: ADAM access fails when authenticating w/ credentials from user within ADAM

You didn't mention enabling the user too. They are often disabled by
default (depending on pwd policy).

The rest of the code looks basically fine. If you set the UPN on the user,
you can use that as the username. This is often more convenient than the
full DN.

Joe K.

<> wrote in message
news: ups.com...
> Here is my setup:
>
> 1. Instance of ADAM on Win2003 Server
> 2. The server is a DC on an regular AD domain
> 3. I migrated all the AD users to ADAM using adamsync.exe
> 4. I created a new user (MyUser) underneath a new OU in ADAM (This user
> is not in AD)
> 5. I set the MyUser's password to "xyzpdq" by using the "Reset
> Password..." context menu in ADAM-adsiedit
>
> When I try to execute the following c# code, I get "Unknown logon or
> bad password" after the RefreshCache call. I've seen a number of
> examples of authenticating an ADAM user and they all use pretty much
> the same code that I do below. Am I inadvertently getting my
> authentication requests routed to the AD forest (instead of ADAM) since
> I am on a DC?
>
> This is the only explanation that I can come up with.
>
> Mike
> ---
>
> strUser = "CN=otherUser,OU=App Users,DC=userdb,DC=adam";
> strPath = String.Concat("LDAP://", strServer, ":", strPort,
> "/", strUser);
>
> AuthTypes = AuthenticationTypes.None;
>
> // Bind to user object using LDAP port.
> try
> {
> objUser = new DirectoryEntry(
> strPath, "CN=MyUser,OU=App
> Users,DC=userdb,DC=adam", "xyzpdq", AuthTypes);
> objUser.RefreshCache(); // exception thrown here
> "unknown user name or bad password"
>
> objUser.UsePropertyCache = false;
> objUser.Properties["customAttribute"].Value = new
> byte[] { 1, 2, 3, 4, 5, 6, 7, 8, 9 };
> objUser.CommitChanges();
> }
> catch (Exception ex)
> {
> Debug.WriteLine("Error: Bind failed.");
> Debug.WriteLine(" {0}.", ex.Message);
> return;
> }
> finally
> {
> if (objUser != null)
> {
> objUser.Close();
> objUser.Dispose();
> }
> }
>

msds-UserAccountDisabled is part of ms-DS-Bindable-Object, so assuming you
have that aux class on your users, you should have it (or at least be able
to set it). This class is needed for any object that will be bindable
(except for things that are bind proxies as I recall), so you would need
this if you are intending to bind against these objects.

I'm not exactly sure what schema you'll end up with following the steps
below, but you can check by examining your own schema.

You might also just try setting this to FALSE using ldp.exe and see what
happens.

Joe K.

<> wrote in message
news: oups.com...
>I looked up how to enable a user, and most common response is to set
> "msDS-UserAccountDisabled" for the user to FALSE. But when I went to
> look at the attributes for my user, that attribute is not listed (I
> have all attributes displayed, not just the ones that are set).
>
> The history of my schema is:
>
> 1. I created a unique ADAM instance from scratch using adaminstall and
> an answer file. I did not import any LDF files during the install.
>
> I wanted to sync users from AD so I ..
> 2. I imported the MS-AdamSyncMetadata.ldf file using ldifde
> 3. I Imported the MS-AdamSchemaW2k3.ldf file ldifde
> 4. I ran adamsync.exe to bring over users from my AD domain
> 5. I ran my own LDF file to add 3 custom attributes to the User schema
>
> Is msDS-UserAccountDisabled the attribute I need, or would it have been
> deleted by one of the sync-related scripts?
>
> Mike
>

That makes sense. I know that the attribute in question comes with
ms-DS-Bindable-Object, but I don't know which of the ADAM ldif files include
it. Lee would know right off the top of his head.

That aux class essentially makes an object "bindable". It can be added to
your own custom schema if you want.

User accounts will be disabled by default if the password policy in effect
requires a password. This depends on the password policy in effect on the
current machine, which is either a local policy or the GPO applied to the
machine from the domain.

You can't get a bindable user object enabled by default if a password is
required.

Note that if you are syncing AD objects and want to bind with the AD user's
password, you should probably be looking at creating bind proxy objects.
That's what they are there for. If you want the ADAM objects to have
separate passwords, then what you are doing is fine.

Joe K.

<> wrote in message
news: oups.com...
> OK, I tried LDP. I tried setting msds-UserAccountDisabled and I get
> "operation not allowed on the target object class" (paraphrasing). So
> I decided to start from scratch and remove the ADAM instance and
> recreate it without sync'ing with adamsync to see just when this
> attribute is added to the "user" class. Then it hit me. Bare-bones
> ADAM has no user class to begin with, but one exists _without_ the
> "msds-UserAccountDisabled" after the AD sync. So there must have been
> a step I was missing.
>
> The step I was missing was to import the MS-User.ldf file before doing
> any of the AD sync steps. MS-User.ldf is the one that contains
> msds-UserAccountDisabled and now everything works as expected!
>
> So the full steps to getting both native ADAM users and migrated AD
> users to authenticate in harmony are:
>
> 1. Create a unique ADAM instance .
> 2. *** Import the MS-User.ldf file that comes with ADAM using ldifde
> ***
> 3. Import the MS-AdamSyncMetadata.ldf file using ldifde
> 4. Import the MS-AdamSchemaW2k3.ldf file ldifde
> 5. tweak your AdamSyncConf.xml as desired
> 6. Run adamsync.exe to bring over users from my AD domain
> 7. Make sure you set msds-UserAccountDisabled to FALSE for any user
> accounts you want to use. (They all seem to be set to TRUE, even the
> migrated ones. There may be a way to set the default to TRUE in the
> adamsync step # 6 but I haven't looked into it)
>
> Joe,
> Thanks for your help, it certainly saved me a boat-load of time.
>
> Mike
>