As far as I know, you can't "integrate" AD into another authentication source directly. AD is the authentication source, as far as Microsoft is concerned. (Also, keep in mind that AD is the more than just LDAP, and Kerberos is a piece of it.)
That said, most of us have to support large environments with multiple LDAP sources, password files, etc. Generally, there will be some kind of synchronization, somewhere. For example, you may have a top-level Identity Management (IdM) solution in place for provisioning and rights management. This IdM application may also provide your employees with a password self-service tool, which will then connect to your systems to update passwords enterprise-wide when a user makes a change (although you may not want to always do this due to partitioning). SSO products do something similar in that they just tie everything together where true SSO isn't possible (say, via Kerberos, and let's be honest: the only platform that has successfully deployed Kerberos as a major component of authentication for the entire application stack in a large number of networks is Windows AD). Really, most SSO solutions are just very comprehensive password management tools. Anyway, at various clients we've seen this problem again and again, and it can be a tad messy, especially if your company is large and supports multiple systems. In that case, just plug as much as possible into LDAP and AD. Let the IdM provision to that. For any non-LDAP-aware applications (and there are more of these than not), the IdM needs to plug directly into that application. Password changes go directly to the self-service tool and/or via a Winlogin plug-in that connects to the same source. That's 99% of it. For smaller sites, say, if you are just running UNIX and Windows, and most of your UNIX systems and applications can do LDAP, then using something like Windows SFU with the Password Synchronization Agent can be helpful. Hope that gives you some food for thought. :) --- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author: "Best Practices for Managing Linux and UNIX Servers" "Spam Fighting and Email Security in the 21st Century" Download your free copies: http://www.puryear-it.com/publications.htm Wednesday, January 31, 2007, 6:00:19 PM, you wrote: > * Quanah Gibson-Mount <[EMAIL PROTECTED]> [2007-01-31 19:59]: >> --On Wednesday, January 31, 2007 12:57 PM -0600 Dustin Puryear <[EMAIL >> PROTECTED]> wrote: >> >Any ADAM-stories would be welcome. :) >> >> It still isn't fully LDAP compliant. Either "cn" or "sn" is only allowed to >> be single-valued, I forget which. > if that was all... > now, how about pointing ADAM (or whatever it is called nowadays) to > OpenLDAP for authentication? I really know nothing about AD but > what I read from the ADAM docs ADAM needs some external DSA for > authentication (most probably AD). > for me the possibility of having some M$-AD-like stuff that actually > integrates with our OpenLDAP based directory services sounds quite > interesting. > and while I'm at it: has anyone some actual data/info on if you or > cannot can integrate M$ AD with some external (MIT, Heimdal) Kerberos > server for authentication? > we're trying to get rid of password syncing so any info on ways > accomplishing this (ADAM, Kerberos) would be appreciated. > regards, > -p.schober > --- > You are currently subscribed to [email protected] as: [EMAIL PROTECTED] > To unsubscribe send email to [EMAIL PROTECTED] with the word > UNSUBSCRIBE as the SUBJECT of the message. --- You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send email to [EMAIL PROTECTED] with the word UNSUBSCRIBE as the SUBJECT of the message.
