Brian explained this properly a few posts back: applications built around generic LDAP must figure out the user's DN based on username/email/UPN that the user typed in, before an attempt to validate the supplied credential can be made. That's where the service account comes in... it just has to search out that user account. Non-AD LDAP servers do not have any common concept of letting a user bind with a bare username or UPN.
Hey, AD-integrated apps have to do this too, and they have a credential squirreled away in a file somewhere--okay, it's heavily obfuscated, but the machine account secret isn't magic. Same deal with a Kerberos keystore. I would note that most non-AD LDAP DSAs allow anonymous to search by default. Requiring a bind before doing certain UNIX'y things (I'm looking at you, automountd) remains a bit kludgy. --Steve On Mon, Oct 3, 2011 at 10:22 PM, Ben Scott <[email protected]> wrote: > On Mon, Oct 3, 2011 at 11:37 AM, Crawford, Scott <[email protected]> > wrote: >> RE: This is a fairly common model and there’s not really anything wrong with >> it. >> Why is it such a common model? I see it a lot too, and it always frustrates >> me that they don’t simply use the credentials supplied by the user to >> attempt to bind to AD. > > I'm confident laziness is the most common reason, but for a minority > of cases, some scenarios have a need to identify things in the > directory independently of a user doing something against that > directory. In other words, the server needs to look something up > without having a user's credentials handy to do so. > > There may also be a performance/security thing. If you're dealing > with a LDAP->Unix gateway (making your LDAP accounts look like > traditional Unix accounts), authenticating each user doing something > would require that many different LDAP connections, and arguably the > host should cache them separately as well (since if you care to do > this you presumably have users with different accesses to your > directory). As having one account for the host that has read-only > access, the host can just use one connection and cache for everybody. > > But whether either of these possibilities apply depends entirely on > the scenario. > > -- Ben > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
