Re: ADAM and Windows Address Book

Tech-Archive recommends: Fix windows errors by optimizing your registry

I'm not sure exactly where this is documented, but I'm sure Lee or Dmitri
will know. There isn't much more to it than that though. If
userPrincipalName or displayName are populated, then they both can be used
as user names for a simple bind against ADAM. Make sure you don't
accidentally create duplicates. :)

It is true that the LDAP V3 spec says that distinguished name must be
supported as the username for a simple bind request, but it leaves open the
possibility that other names can be used as well. AD and ADAM both take
advantage of this. AD supports the userPrincipalName and NT logon name
(domain\user), in addition to DN, for simple binds. ADAM supports UPN and
displayName (and maybe some others; I forget all the details).

Given that your users probably all know their UPN from AD, you should be
able to sync that to ADAM as part of your sync process and then have them
use that directly. Typically, your UPN in AD will also be unique (or the
user won't be able to log in there), so you should be able to take advantage
of that uniqueness in your sync to ADAM to get the same results. This is
what I would do if I were in your shoes. :)

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Rich Raffenetti" <raffenetti@xxxxxxxxxxx> wrote in message
news:eU0ytrq4GHA.3736@xxxxxxxxxxxxxxxxxxxxxxx
Sounds good. Is there a reference I can consult for more details?

"Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:ete2LNq4GHA.4256@xxxxxxxxxxxxxxxxxxxxxxx
You can set the userPrincipalName attribute or displayName attribute on
an object in ADAM and use that as an alternate binding username so you
don't have to use the full DN.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Rich Raffenetti" <raffenetti@xxxxxxxxxxx> wrote in message
news:%23UXWbjp4GHA.4832@xxxxxxxxxxxxxxxxxxxxxxx
Thanks for the reference. I have the following comments:

1. There appears to be an error in the blog. The following is correct I
believe
<user-proxy>
<source-object-class>user</source-object-class>
<target-object-class>user-Proxy</target-object-class>
</user-proxy>
Note that I have substituted >user-Proxy< for >userProxy<. Prior to
this
change, the synchronization would not process.

2. As I understand this, each user entry becomes a user-Proxy instead.
I presume this does not affect queries.

3. With the proxy authentication, the syntax of the username that users
need to configure in order to authenticate changes from <username> to
cn=<username>,<search base>, for example, cn=jack,o=Microsoft,c=US.
This seems to be the LDAP authentication standard but is certainly not
what I wish to tell my users! I would like them to enter username,
password, and domain because that is what they are used to doing.

I am disappointed in the defective WAB.


"Dmitri Gavrilov [MSFT]" <dmitrig@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23BDSIXT3GHA.4024@xxxxxxxxxxxxxxxxxxxxxxx
Eric's blog is the best doc for ADAMSync.
http://blogs.technet.com/efleis/archive/2005/09/23/411473.aspx


--
Dmitri Gavrilov
SDE, Active Directory team

This posting is provided "AS IS" with no warranties, and confers no
rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Rich Raffenetti" <raffenetti@xxxxxxxxxxx> wrote in message
news:%230shngR3GHA.4972@xxxxxxxxxxxxxxxxxxxxxxx
Thanks. Could you tell me an example of the ADAMSync command that
will
create the user-->bindproxy conversions for me. I missed that.
Thanks.

"Dmitri Gavrilov [MSFT]" <dmitrig@xxxxxxxxxxxxxxxxxxxx> wrote in
message
news:%23stEH2I3GHA.696@xxxxxxxxxxxxxxxxxxxxxxx
WRT R2 ADAM -- sorry to disappoint you, but you have no reason to
move
to R2. ADAM SP1 and ADAM R2 are the same exact set of binaries. So,
adamsync that you have will do user->bindproxy conversions for you.

--
Dmitri Gavrilov
SDE, Active Directory team

This posting is provided "AS IS" with no warranties, and confers no
rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

"Rich Raffenetti" <raffenetti@xxxxxxxxxxx> wrote in message
news:OG5HV442GHA.4796@xxxxxxxxxxxxxxxxxxxxxxx
I understand from another posting that it is the R2 ADAMSync that
will
create bindproxies for me. I have been using the ADAM/SP1. I hope
the
documentation is updated!

Since we want to provide an ADAM as a secure alternative to punching
holes in the firewall for AD, we are really playing to all platforms
that have their own address book-like application. I would expect
to
serve many WAB users too, of course.

Our AD is the repository for all employee accounts, whether they be
for
Windows, Macintosh, or linux/unix. Most platforms have email
systems
that utilize an LDAP lookup. If I couldn't make it work for WAB,
how
could I serve the others.

My experience with one or two other address book applications is
that
they do well for anonymous lookups and not so well for authenticated
lookups. WAB is like that too. ;-)

However, with the proxied authentication that you refer to here, I
would expect that the authentication will work better like WAB and
we
will use SSL/636 to protect the password and data stream.

Should I understand it that the new R2 ADAMSync will do the proxy
setup
for each account - avoiding the incredibly difficult process
described
in the ADAM/SP1 system? That would be great! (I don't appreciate
what
DirSync is.) :-(

I knew I had a good reason to move to the R2 ADAM. We just recently
installed the R2 schema extensions in production! This is great
news!
:-)

"Lee Flight" <lef@xxxxxxxxxxxxxxx> wrote in message
news:uELwthv2GHA.4164@xxxxxxxxxxxxxxxxxxxxxxx
I have little to add to that other than:

ADAMSync will do AD user to ADAM bindproxy transforms
for you (it just does DirSync under the hood).

Do you really need WAB as opposed to writing your own address
book application. Spending some time with a copy of JoeK's book and
rolling your own app might be a better investment than increasing
your
reliance on WAB at this time.

Lee Flight


"Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:eMN2NgQ2GHA.1288@xxxxxxxxxxxxxxxxxxxxxxx
Lee is a better guy to ask on sync options. I haven't done this
yet.
The bottom line is that you could write a program to do this for
you
and ADSI can support this, although not really well with script or
VB6. You are looking at C++ or .NET 2.0, as you really need the
DirSync control to do this well, and script doesn't (and won't)
have
access to this.

Most people would suggest you get a product that does this, but
I'm
not sure about the status of things like ADAMSync with respect to
bindProxies. Last I remember, that wasn't supported but was maybe
coming soon.

Basically, the bind proxy allows your users to hard code their AD
credentials in the WAB settings in order to authenticate. The
advantage here is not having to give out the password to a fixed
account, but there are disadvantages too. If users change
passwords
in AD and forget to update WAB, WAB will stop working and will
lock
out their account if they try repeatedly (and you enforce pwd
lockout). That creates a potentially costly support nightmare.

Another potential option to avoid the whole problem is changing
ADAM
to allow anonymous searches and ACLing the stuff in ADAM
appropriately such that the anonymous user can see only the things
you want them to in the address book. This is obviously less
secure,
but has a big upside in terms of both of the other two scenarios
in
terms of desktop management nightmares. Your particular
requirements
will have to guide you here. :)

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Rich Raffenetti" <raffenetti@xxxxxxxxxxx> wrote in message
news:uSrnfPQ2GHA.5048@xxxxxxxxxxxxxxxxxxxxxxx
I read about the bindProxy objects and setting one up for each
user
and keeping them synchronized scares me a bit. Has anyone written
an
ADSI program (or equivalent) to create the bind objects? Of
course,
this wouldn't be necessary if WAB was fixed.

"Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message news:eIzZu5M2GHA.480@xxxxxxxxxxxxxxxxxxxxxxx
Yes, the issue appears to be with the implementation of WAB and
not
a problem with ADAM or SSPI per say. SSPI is certainly capable
of
using the current thread's credentials OR using specific
credentials, but WAB is not taking advantage of the latter for
some
reason, even though the UI would seem to indicate that it would.

If specific credentials need to be used, it seems to me that the
ony solution for Rich is to create a service account in ADAM and
use that (or create bindProxy objects for each user if it is
important that each user use their own passwords). This would
accomodate the simple bind case, which WAB seems to work with.
Since SSL is in use, this would be secure.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Lee Flight" <lef@xxxxxxxxxxxxxxx> wrote in message
news:uuGW43J2GHA.4484@xxxxxxxxxxxxxxxxxxxxxxx
Hi

inline below...

"Rich Raffenetti" <raffenetti@xxxxxxxxxxx> wrote in message
news:OtYwK%23G2GHA.4108@xxxxxxxxxxxxxxxxxxxxxxx
I really appreciate your testing and results.

So let me see if I understand it.

Since I need a Windows login, the simple bind is of little
interest.

If I want a Windows login to ADAM from Address Book, I must be
logged into a domain account.

That is because the SSPI logon uses the credentials of the
logged
on account. If the logged on account is not a domain account,
then no authentication can take place because ADAM does not
authenticate accounts that are not either ADAM accounts or
Windows accounts for the domain that ADAM is in.

The bind method distinguishes for ADAM between windows accounts
(domain or
local to the ADAM instance) and native ADAM accounts. An SSPI
connection
must be a windows account from ADAM perspective and the only
authorities
ADAM can appeal to for auth of the account are domain (joined
to
or trusted)
and the OS ADAM server is running on. If the only credentials
WAB
can offer
over SSPI are those of the logged on account that runs WAB and
if
that account
is not auth'ed by an authority ADAM has access to then there's
no
access.


A conclusion is: The username/password supplied to the Address
Book properties pages is not used for authentication to the
ADAM
instance - ever! If I report this to MS, will it be considered
a
bug? Are any hotfixes known for this?

The username/password in WAB can be used for a simple bind
(with
or without
SSL) using credentials of an account that is native to ADAM.
SPA
must be
unchecked for this to work. WAB is clunky, the real problem is
as
JoeK pointed
out that the use of credentials and the selection of "SPA" in
the
interface should
be mutually exclusive (and also no one knows what "SPA" means).
IMO WAB and the Outlook LDAP Address Book could both do with a
refresh;
googling around it seems like WAB may be replaced in vista.

I believe Address Book fails the same way when pointed
directly
at an Active Directory domain rather than an ADAM LDAP
instance!

Pointing WAB at a DC the only authority is the domain (or
trusted
domain)
no local windows SAM auth, clearly any non domain account will
fail to auth.
However unchecking SPA and entering domain credentials (in
appropriate form)
will work against AD (SSL may be required depending on policy)
as
the simple
bind with windows credentials will be authenticated by AD.

Lee Flight


























.

Relevant Pages

  • Re: ADAM and Windows Address Book
    ... credentials instead of a fixed service account. ... it is a special LDAP control supported by AD and ADAM ... If I couldn't make it work for WAB, ... credentials in the WAB settings in order to authenticate. ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM and Windows Address Book
    ... If I couldn't make it work for WAB, ... I knew I had a good reason to move to the R2 ADAM. ... credentials in the WAB settings in order to authenticate. ... account, ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM and Windows Address Book
    ... If I couldn't make it work for WAB, ... I knew I had a good reason to move to the R2 ADAM. ... credentials in the WAB settings in order to authenticate. ... account, ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM and Windows Address Book
    ... If I couldn't make it work for WAB, ... each account - avoiding the incredibly difficult process described in the ... I knew I had a good reason to move to the R2 ADAM. ... the current thread's credentials OR using specific credentials, ...
    (microsoft.public.windows.server.active_directory)
  • Re: ADAM and Windows Address Book
    ... WAB, WAB will stop working and will lock out their account if they try ... Another potential option to avoid the whole problem is changing ADAM to ... the current thread's credentials OR using specific credentials, ...
    (microsoft.public.windows.server.active_directory)