Re: ADAM Authentication
- From: "Joe Kaplan \(MVP - ADSI\)" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Fri, 21 Jul 2006 12:42:01 -0500
I'm not sure if this is involved or not, but part of the problem may be in
network issues with secure authentication. Generally, with secure auth, the
client needs to contact the KDC to get a Kerberos ticket for Kerberos login
or may need to contact the DC for NTLM. That may not work for clients
outside the firewall.
If you can do a simple bind though, you don't have that issue. The
credentials are passed directly to the ADAM server via LDAP. It appears
that you uncheck the secure password authentication box if you want a simple
bind. The primary concern there is that simple binds are not secure unless
the channel is encrypted with SSL or something. However, you said you
already have SSL.
You might consider creating a fixed service account in ADAM with a password
that doesn't expire and giving it read access to the address data. Then,
you configure your clients with that ADAM ID and it should work in any
network configuration that can hit your ADAM instance via SSL/LDAP (and
trust the certificate). You could also put bind proxies in your ADAM
instance and have your users put their own IDs in the WAB configuration, but
then they'd have to remember to change those credentials whenever they
change passwords or risk lockout.
Just an idea...
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
--
"Aaron" <Aaron.Smith@xxxxxxxx> wrote in message
news:1153500440.682492.326810@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Yes, Secure Password Authentication is checked on.
Dmitri Gavrilov [MSFT] wrote:
Did you check "Use Secure Password Authentication" checkbox? Without it,
WAB
will attempt to do a simple ldap bind.
--
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
"Aaron" <Aaron.Smith@xxxxxxxx> wrote in message
news:1153426568.695381.255790@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
The client app in question is the Windows Address Book. Part of
Microsoft Outlook Express. So...yeah...I do that right after I go wash
some dirt.
Joe Kaplan (MVP - ADSI) wrote:
That's what I was trying to suggest. This sounds like a bug in the
client
app you are using. You might want to report this to whoever owns that
piece
of code.
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
--
"Aaron" <Aaron.Smith@xxxxxxxx> wrote in message
news:1153401951.420758.128500@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
But I'm not trying to authenticate as HOME\joebob. I'm providing
the
username and password for CAMPUS\aaron and want ADAM to authenticate
THAT. It's Microsoft Outlook Express that is trying to send the
HOME\joebob credentials instead of the CAMPUS\aaron credentials that
I
have configured for the LDAP account i the address book. Other LDAP
applications don't seem to have this problem. The ADAM ADSI editor
*and* ldp.exe will both connect and auth/bind from the HOME/joebob
computer using the CAMPUS\aaron credentials.
Dmitri Gavrilov [MSFT] wrote:
ADAM can only authenticate users that are trusted. It won't allow
HOME\joebob access its data because it does not know who
HOME\joebob
is.
It
is as good as anonymous, as far as ADAM is concerned. If some
computer
on
the internet authenticated joebob and is saying "this guy is really
authenticated. Oh, and he is a member of BUILTIN\admins too", it
does
not
mean ADAM should trust that computer to do a good job
authenticating.
If HOME was a domain, then you could create a trust from CAMPUS to
HOME,
and
then ADAM would be able to authenticate users from HOME. However,
from
your
scenario, I don't think that is possible.
--
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
"Aaron" <Aaron.Smith@xxxxxxxx> wrote in message
news:1153339803.037160.225080@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Ok. So I'm working on creating an Addressbook for domain users
that
can be access remotely via LDAP. I've setup an ADAM instance and
have
ported the user/mail information from our Active Directory domain
into
this instance. If i'm using something like Windows Address Book
(wab.exe) from an account that is logged in to the domain, and
bind
to
ADAM using a windows domain security principal, then it works
fine.
However, if I attempt to bind to the ADAM instance using that
same
domain security principal while logged into an external machine
that
is
NOT a part of our domain (or part of a different domain) then the
authentication/bind fails. From looking at the packet traffic,
it
appears to be attempting an authentication useing the credentials
of
the logged in user. For Example:
Lets say my domain username is CAMPUS/aaron. If I'm logged in to
my
workstation as CAMPUS/aaron and bind to ADAM using CAMPUS/aaron,
it
works fine. However, if I go home, and log into HOME/joebob, and
then
configure wab to bind to the ADAM server back at work using the
CAMPUS/aaron username and password, the authentication fails and
I
would see an authentication attempt using HOME/joebob.
What do I need to do to allow my domain users to be able to
authenticate to the ADAM instance when they are NOT logged in to
the
domain itself? Keep in mind that I do *not* wish to use
anonymous
binding, users *must* authenticate before using the directory...
.
- References:
- ADAM Authentication
- From: Aaron
- Re: ADAM Authentication
- From: Dmitri Gavrilov [MSFT]
- Re: ADAM Authentication
- From: Aaron
- Re: ADAM Authentication
- From: Joe Kaplan \(MVP - ADSI\)
- Re: ADAM Authentication
- From: Aaron
- Re: ADAM Authentication
- From: Dmitri Gavrilov [MSFT]
- Re: ADAM Authentication
- From: Aaron
- ADAM Authentication
- Prev by Date: Re: actively loggon computers accounts - inventory
- Next by Date: Re: actively loggon computers accounts - inventory
- Previous by thread: Re: ADAM Authentication
- Next by thread: Re: ADAM Authentication
- Index(es):
Relevant Pages
|