Re: ADAM and Windows Address Book

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)