<br><font size=2><tt>eichin@metacarta.com wrote on 08/14/2005 12:17:31
PM:<br>
<br>
> I suspect the original mention of LDAP was a bit of a distraction
-<br>
> that's only useful for authORIZATION (ie. getting lists of groups
and<br>
> acls that a user has and *deciding* what they can do, once you know<br>
> who they are - it's the knowing who they are part that is<br>
> authENTICATION, which is done with kerberos.)<br>
</tt></font>
<br><font size=2><tt>I haven't even started working on authorization. The
first problem</tt></font>
<br><font size=2><tt>is just basic authentication. Some LDAP servers, such
as Active Directory,</tt></font>
<br><font size=2><tt>supposedly supports authentication with queries, so
if a username and</tt></font>
<br><font size=2><tt>password are included as parameters to a query, they
will be handled</tt></font>
<br><font size=2><tt>appropriately. The part I'm not yet clear on has to
do with the</tt></font>
<br><font size=2><tt>requirements on such queries. For instance, Apple's
OpenLDAP comes</tt></font>
<br><font size=2><tt>with SASL authentication, but I haven't yet gotten
that to work.</tt></font>
<br><font size=2><tt>I've tried testing various parameters to the ldapsearch
command,</tt></font>
<br><font size=2><tt>for instance:</tt></font>
<br>
<br><font size=2><tt>ldapsearch -h adserver.ourdomain.org -D "cn=myuserid"
-w mypassword -b "dc=OURDOMAIN,dc=ORG"</tt></font>
<br>
<br><font size=2><tt>...and here is the error I get on Mac OS 10.4.2:</tt></font>
<br>
<br><font size=2><tt>SASL/GSSAPI authentication started</tt></font>
<br><font size=2><tt>ldap_sasl_interactive_bind_s: Local error (-2)</tt></font>
<br><font size=2><tt> additional info: SASL(-1):
generic failure:</tt></font>
<br><font size=2><tt>
GSSAPI Error: Miscellaneous failure (No credentials
cache found)</tt></font>
<br><font size=2><tt><br>
> It doesn't make any sense to me that the *client* would do ldap<br>
> authorization lookups, simply because it could just as easily "make
up<br>
> answers" and present them to the server - the client is on the
wrong<br>
> side of the trust boundary...<br>
</tt></font>
<br><font size=2><tt>I thought one of the key concepts of Kerberos was
that the password</tt></font>
<br><font size=2><tt>is only ever sent to the authentication server by
a client, and that</tt></font>
<br><font size=2><tt>the username and password would never be sent to the
application server.</tt></font>
<br><font size=2><tt>Instead, a Kerberos ticket would be sent, and the
application server</tt></font>
<br><font size=2><tt>would inspect the ticket for validity. Therefore,
the client should</tt></font>
<br><font size=2><tt>never need to send a password to the app server, and
the app server</tt></font>
<br><font size=2><tt>would never be in a position to collect user passwords.</tt></font>
<br>
<br><font size=2><tt>> What the original left out was: how do the client
and server talk to<br>
> each other? The most common case is for the server to be HTTP
and the<br>
> authentication to be "Negotiate", which ends up either passing
GSSAPI<br>
> tokens or falling back to NTLM (which is, hopefully, disabled.)<br>
</tt></font>
<br><font size=2><tt>The client and server communicate via XML-RPC in the
case of the</tt></font>
<br><font size=2><tt>app I'm working on.</tt></font>
<br><font size=2 face="sans-serif"><br>
<b><br>
Brad Allen</b><br>
IT Desktop Support<br>
</font><img src=cid:_2_0A17BF940A17B89C005AEE138625705E><font size=2 color=blue face="sans-serif"><u><br>
</u></font><a href=mailto:brad.allen@omsdal.com><font size=2 color=blue face="sans-serif"><u>brad.allen@omsdal.com</u></font></a><font size=2><tt><br>
<br>
</tt></font>