Re: ADAM - AD_Schema load fails with error



Hi,

Thanks again for all your help. Sorry if I am not quite getting this right.

It sounds like you are saying that the passwords are not bought down by
adamsync (or MIIS) and I need to use some product to sync the passwords
separately, but MIIS won't do the trick as it only synchronizes changes as
they happen.

If ADAMSync is bringing accounts into ADAM as native accounts... reading the
technical doc it seems that it normally they will do a simple LDAP bind to
ADAM and have no need to access AD or local windows accounts. It only seems
to need to need this if ADAM recognises it as a windows principal. I wonder,
when is an account considered a Windows principal?

I am trying to authenticate using the .NET code;
DirectoryEntry de = new DirectoryEntry(Domain,User,Pass)

....and as ADAM doesn't have the password, is it then passing it to AD to
authenticate?

--
Regards,
Andrew Stanford


"Lee Flight" wrote:

> Hi
>
> inline below...
>
> "Andrew Stanford" <AndrewStanford@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
> message news:741F8B65-50EA-48E7-AD37-93A500309AFA@xxxxxxxxxxxxxxxx
>
> > Thanks for the link. It does clarify things. What I get is that any
> > accounts
> > bought into ADAM using ADAMSYNC are flagged inside the ADAM instance
> > somewhere as Windows Principals.
>
> User objects in AD pulled by ADAMSync will get instantiated as native
> ADAM user objects (as defined by the user classSchema object that you
> imported into your ADAM schema). In fact, in the R2 version you could
> map them to userProxy objects but that is not the default. So you should
> have a native ADAM user for each AD users i.e. an ADAM user object
> whose attributes have been sync'ed from AD but which will need
> passwords setting if you want to authenticate against them. Of course
> you might not want to authenticate against them you might just want them
> as a catalog of your AD users, although I'm not clear whether you even
> need that information depends on your application's requirement.
>
> > So if I want to do local authentication I
> > need ADAM native accounts.
>
> or Windows users local to the ADAM server
>
> > You mentioned password synchronization... we have been also looking at
> > Identity Integration Server as an alternative to ADAMSYNC to populate
> > ADAM. I
> > see that this isn't going to help us as the accounts are likely to be
> > flagged
> > as Windows Principals,
>
> They will not be Windows Principals, see above. Windows Principals
> are domain accounts defined in your AD, your ADAMSync'ed objects
> are shadows of the domain accounts - ADAM user objects that have
> some attributes that are the same as the domain accounts, think of
> the ADAM objects as a catalog of the AD objects.
>
> > but I guess what you might be saying is that it may be
> > possible for us to populate ADAM with just the usernames from AD using
> > ADSI,
> > then use MIIS to sync the passwords.
>
> If you use MIIS/IIFP then it will sync the objects but with greater
> flexibility
> than ADAMSync; the MIIS/IIFP password synch mechanism is based
> on intercepting password when a password is *changed* in AD as existing
> passwords cannot be extracted from AD.
>
> Lee Flight
>
>
>
.



Relevant Pages

  • Re: ADAM - AD_Schema load fails with error
    ... > If ADAMSync is bringing accounts into ADAM as native accounts... ... ADAM distinguishes between accounts dependent on how they bind ... In particular you might grant Windows principals access ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM - AD_Schema load fails with error
    ... However, in .NET, the default is to always use Secure bind ... > used on different types of users (ADAM or bind proxy users vs. pass through ... >>> If ADAMSync is bringing accounts into ADAM as native accounts... ... In particular you might grant Windows principals access ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM - AD_Schema load fails with error
    ... > bought into ADAM using ADAMSYNC are flagged inside the ADAM instance ... > somewhere as Windows Principals. ... User objects in AD pulled by ADAMSync will get instantiated as native ... > need ADAM native accounts. ...
    (microsoft.public.windows.server.active_directory)
  • Re: Architectural question for product security deployment
    ... ADAM uses the local and domain policies where it's installed. ... Also, to change passwords via LDAP, you must connect via a secure method by ... bit (may not work in workgroup setting; you may need an alternate method, ... > 1) I Installed ADAM by first logging in a system admin and creating the ...
    (microsoft.public.windows.server.active_directory)
  • Re: password expiration policy for admin and system accounts ?
    ... policy that Admins manually reset these important account passwords every ... You can still have the passwords set to never expire, ... > Privileged accounts should be the most, not the least, well guarded. ...
    (microsoft.public.security)

Loading