Re: How to add an extra password field to an AD?
- From: "Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 18 Jul 2007 18:17:15 -0500
Replies below inline. I think the overall concern is likely just that you
need to find a way to store this data in AD securely. Try starting a new
thread on that topic.
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
--
"Marc Haber" <mh+usenetspam200729@xxxxxxxxxxxx> wrote in message
news:OZlQU5QyHHA.536@xxxxxxxxxxxxxxxxxxxxxxx
Joe Kaplan wrote:
Your AD administrators are not quite correct, in that it is possible to
put data into AD that is not world-readable. It isn't totally
straightforward, but it can be done.
Good news. What do I need to tell them?
Guido Grillenmeier (sp?) did a great presentation on this at DEC 2006 that
covers the topic well. Maybe you can dig that up? You might want to start
a different post about this particular question as it is a big topic.
Explain how this application is going to authenticate AD users if it
isn't going to use the AD user's password, but a different password. Is
that not in effect a different user? What is the point?
It is in effect a different set of credentials, but one that can be
administrated right beside the "normal" AD stuff, goes away when the AD
user is locked or deleted, and has an administration interface that the
people are already familiar with.
The point is that the service password is likely to be _stored_ on the
client system and is easy to compromise. In that case, I'd like the AD
password (which gives access to the Windows resources) to stay safe.
You cannot add another attribute to AD and have that be used for an LDAP
bind operation, so you cannot do what you want to do anyway, assuming
that the device in question uses a standard LDAP bind to do LDAP
authentication.
I have some control about the LDAP connector. It is open source ;)
I guess we aren't really connecting here, because I'm saying that from the
AD server perspective, you can't change how bind authentication works. If
you are changing a client, that's different, but my response was based on my
understanding that you were trying to make AD use this password which you
cannot.
Plaintext credentials are not necessarily a problem from a networking
perspective if you use SSL.
SSL cannot be used here since the protocol being used does not have an SSL
variant. ALso, my real concern (sorry if I didn't write that clear enough
in the original messag) is the password being stored on the client system.
There are enough services (think SIP with a mainstream VoIP telephone)
that do not allow SSL to be used.
See above. If this doesn't involve an actual LDAP bind to AD, then I guess
I don't really care. Since you won't be changing how that is done, then you
can secure your protocol however you need to.
Both AD and ADAM can be configured with an SSL certificate for LDAP
traffic, so that might help mitigate that risk.
My concern is not the LDAP traffic between the service server and the LDAP
server, it is between service client and service server.
If the problem is really that you don't want this app to have access to
the user's plaintext credentials and it doesn't support Windows
authentication (Kerberos/NTLM), then I don't see how you can reconcile
that requirement with the desire to authenticate against AD.
I actually don't want the app to see AD passwords that give access to
Windowws resources. I don't care whether the app sees its own passwords.
Greetings
Marc
.
- References:
- Re: How to add an extra password field to an AD?
- From: Marc Haber
- Re: How to add an extra password field to an AD?
- Prev by Date: Re: Issuing tickets from N DCs and how to control
- Next by Date: RE: Can't join a domain
- Previous by thread: Re: How to add an extra password field to an AD?
- Next by thread: Re: How to add an extra password field to an AD?
- Index(es):
Relevant Pages
|
