LDAP vs authentication

  • 317 Views
  • Last Post 13 June 2016
davyp posted this 08 June 2016

Hi all, I am having a bit of a debate with a Linux dude at the office and perhaps someone here can shed some light on this :-) One of us claims that LDAP is merely the protocol to query a directory over the network in the sense of a phonebook.
Much as with SQL server you can query a database with the the SQL language, but before any SQL queries come into play, you need to authenticate to the database server using standard authentication processes (present a Kerberos token) that have no dependency on the SQL protocol. The other one feels that in the logon process, the backend user database is integrated into LDAP to the extent that when a user logs into Active Directory, the kerberos dlls on the domain controller use ldap to query the password in the DB to be verified. In essence its about the role that LDAP plays in a directory like Active Directory, are there directories that use Kerberos for authentication but have absolutely nothing to do with LDAP (e.g. could you add Kerberos as a feature to an NT4 domain without abandoning Kerberos standards?) Best regards,
DavyP  

Order By: Standard | Newest | Votes
chriss3 posted this 08 June 2016

Yes – Authentications is handled by the KDC.. The datastore (the database in this case is ESE/Jet Bule) and it’s data can be accessed/queried both by LDAP and RPC (SAMR, LSAR, DS RPC) – some of the protocols allow different information to be accessed, for example the password hashes is not readable over LDAP, but over RPC, there is special code paths in the DBLayer specially designed for the KDC to featch group membership to build up the token etc. 

show

bdesmond posted this 08 June 2016

You can think of Kerberos and LDAP as two protocols that sit on top of the Active Directory database. Under the covers, there’s a lower level interface that

they both use to actually get data out of the database.

 

You could certainly stand up an MIT Kerberos realm independently and not have it have anything to do with an LDAP directory and AD.



 



Thanks,

Brian Desmond

 

w – 312.625.1438 | c – 312.731.3132



 

show

barkills posted this 08 June 2016

Jumping even deeper, the LDAP protocol defines a Bind operation as one of its ten operations. It’s that bind operation that is at the heart of the term “LDAP

authentication.”

 

Each LDAP server supports different authentication methods, but by RFC there are two that must be supported: Simple & SASL. Under the covers of those

two methods, there are lots of details.

 

Long ago, I had similar confusion about the LDAP authentication term, and what it really meant, even though I had written an intro book on LDAP. I went on to

write this page:

https://itconnect.uw.edu/wares/msinf/authn/ldap/ldap-authentication-primer/ which dives a level deeper into LDAP authentication. You can look at that page to get a little deeper and have some points of reference for your disagreement—it includes a bunch

of terms and RFC references.

 

The content of that page has been hosted at various other URLs in the past and just recently was moved to this new location.

 

Brian

 

show

DonH posted this 09 June 2016

Almost.  Kerberos and LDAP are both incomplete protocols.  Kerberos specifies how to perform authentication and implies the need for a user database, but glosses over how that database is managed or accessed.  LDAP specifies how a distributed object database is organized and accessed and implies the need for an authentication system, but glosses over how that authentication system is managed or accessed. Active Directory, in the proud design tradition of Reese’s Peanut Butter Cups, combined these two great services into one process where they work great together.  In an AD Domain Controller, the Kerberos Key Distribution Center (KDC) and the LDAP Directory System Agent (DSA) are implemented as mutually interdependent DLLs in the LSASS service.  The KDC and the DSA separately offer both standard protocol access to clients and trusted entry points to their partner DLLs.  Note that those trusted entry points aren’t protocols, aren’t RPCs, and certainly aren’t APIs, they’re just DLL entry points that can only be called in process. This gives the KDC custom, private, secure, access to a directory server, and the DSA custom, private, secure, access to an authentication system.  Note specifically that the KDC thus gets access to the DSA, but has no direct access to the DSA’s database. The DSA entry points include some of the internal worker functions (e.g., “DirSearch”) that the LDAP protocol head calls, but they emphatically aren’t LDAP. (Internally things are, of course, a bit messier.  There is a mechanism for the KDC to freeze the client context and get a fresh new context so that it could call the DSA as itself rather than as the client, but sometimes the DSA might need to call the KDC in order to satisfy that call, which might then need to call the DSA, etc.  There was a limit on how many levels of this kind of recursion we’d allow.  I recall many cases of DS and security developers staring at the same debugger screen trying to figure out whether this was a legitimate case and we needed to increase the “thread states per thread” limit or if it wasn’t legitimate and if so whose code should have prevented it.  There were some cases where getting the ticket info necessary for a DC to RPC to a DC in another domain was like building a house of cards.  Ah, good times.) Ex-DonH 

show

duykato posted this 09 June 2016

You're a genius. By reading this thread I've become 10x smarter.
On Jun 9, 2016, at 11:22 AM, Don Hacherl <don@xxxxxxxxxxxxxxxx> wrote:

show

a-ko posted this 11 June 2016

I would have always enjoyed an AD internals book L (akin to Windows Internals by Russinovich).

Tidbits of knowledge like this are incredibly useful to know! Thanks for sharing. -Mike

show

From: ActiveDir-owner@xxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Don Hacherl
Sent: Thursday, June 9, 2016 14:22
To: ActiveDir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] LDAP vs authentication Almost.  Kerberos and LDAP are both incomplete protocols.  Kerberos specifies how to perform authentication and implies the need for a user database, but glosses over how that database is managed or accessed.  LDAP specifies how a distributed object database is organized and accessed and implies the need for an authentication system, but glosses over how that authentication system is managed or accessed. Active Directory, in the proud design tradition of Reese’s Peanut Butter Cups, combined these two great services into one process where they work great together.  In an AD Domain Controller, the Kerberos Key Distribution Center (KDC) and the LDAP Directory System Agent (DSA) are implemented as mutually interdependent DLLs in the LSASS service.  The KDC and the DSA separately offer both standard protocol access to clients and trusted entry points to their partner DLLs.  Note that those trusted entry points aren’t protocols, aren’t RPCs, and certainly aren’t APIs, they’re just DLL entry points that can only be called in process. This gives the KDC custom, private, secure, access to a directory server, and the DSA custom, private, secure, access to an authentication system.  Note specifically that the KDC thus gets access to the DSA, but has no direct access to the DSA’s database. The DSA entry points include some of the internal worker functions (e.g., “DirSearch”) that the LDAP protocol head calls, but they emphatically aren’t LDAP. (Internally things are, of course, a bit messier.  There is a mechanism for the KDC to freeze the client context and get a fresh new context so that it could call the DSA as itself rather than as the client, but sometimes the DSA might need to call the KDC in order to satisfy that call, which might then need to call the DSA, etc.  There was a limit on how many levels of this kind of recursion we’d allow.  I recall many cases of DS and security developers staring at the same debugger screen trying to figure out whether this was a legitimate case and we needed to increase the “thread states per thread” limit or if it wasn’t legitimate and if so whose code should have prevented it.  There were some cases where getting the ticket info necessary for a DC to RPC to a DC in another domain was like building a house of cards.  Ah, good times.) Ex-DonH From: ActiveDir-owner@xxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx] On Behalf Of Brian Desmond
Sent: Wednesday, June 08, 2016 1:10 PM
To: ActiveDir@xxxxxxxxxxxxxxxx
Subject: RE: [ActiveDir] LDAP vs authentication You can think of Kerberos and LDAP as two protocols that sit on top of the Active Directory database. Under the covers, there’s a lower level interface that they both use to actually get data out of the database. You could certainly stand up an MIT Kerberos realm independently and not have it have anything to do with an LDAP directory and AD.  Thanks,Brian Desmond w – 312.625.1438 | c – 312.731.3132 From: ActiveDir-owner@xxxxxxxxxxxxxxxx [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxx] On Behalf Of davyp@xxxxxxxxxxxxxxxx
Sent: Wednesday, June 8, 2016 3:00 PM
To: ActiveDir@xxxxxxxxxxxxxxxx
Subject: [ActiveDir] LDAP vs authentication Hi all,I am having a bit of a debate with a Linux dude at the office and perhaps someone here can shed some light on this :-)One of us claims that LDAP is merely the protocol to query a directory over the network in the sense of a phonebook.
Much as with SQL server you can query a database with the the SQL language, but before any SQL queries come into play, you need to authenticate to the database server using standard authentication processes (present a Kerberos token) that have no dependency on the SQL protocol.The other one feels that in the logon process, the backend user database is integrated into LDAP to the extent that when a user logs into Active Directory, the kerberos dlls on the domain controller use ldap to query the password in the DB to be verified.In essence its about the role that LDAP plays in a directory like Active Directory, are there directories that use Kerberos for authentication but have absolutely nothing to do with LDAP (e.g. could you add Kerberos as a feature to an NT4 domain without abandoning Kerberos standards?)Best regards,
DavyP 

DonH posted this 12 June 2016

There are dozens of you.  Dozens! 

show

mtopper posted this 12 June 2016











I think many would find it fascinating, either a technical book like Windows Internals or something like Showstopper! about how it came to be.




Probably sell a solid 50 copies, at least!




Sent from my Verizon Wireless 4G LTE DROID





Don Hacherl <don@xxxxxxxxxxxxxxxx> wrote:







There are dozens of you.  Dozens!

 

show

michael1 posted this 13 June 2016

Hey – I think another few dozen Exchange people might buy it too.

J

 

show

webster posted this 13 June 2016

And there is a Citrix guy who would buy it.

 

show

mcasey posted this 13 June 2016

I may buy two copies just to drive up sales.


show

Close