is that common to use kerberos authentication for SUN iplanet LDAP server?

Craig Huckabee huck at spawar.navy.mil
Fri Sep 2 08:00:15 EDT 2005



I'm sorry, I didn't make what we're doing clear.  Our MIT KDC is our 
master for our realm, our AD domain trusts that realm.  We 
add/modify/delete users on our MIT KDC & AD based on our LDAP directory.

All of our user's passwords are kept solely by the KDC.  The GSSAPI LDAP 
module also includes PAM functionality so our LDAP servers use pam_krb5 
to authenticate - so no crypted password hashes in LDAP.  When we push 
down the users to AD, we set the password field there to a long, random, 
  good, password - the trust allows the users to authenticate solely 
from the MIT KDC.

So, in the AD case, we just set the appropriate LDAP attribute for each 
user to the crypted passwd string.  This user replication process is one 
of the many tools that uses Perl-LDAP & GSSAPI/SASL.

Our tools we give our users to change their password (web based, Unix 
kpasswd, and Windows Ctrl-Alt-Del still works) only need to change it on 
the MIT KDC.  Those tools use the standard library functions or the 
Windows equivalent.

Now if only Microsoft would fix their PKINIT implementation so it would 
pass requests to trusted domains like the password functions do I'd be 
happy.

Thanks,
Craig




Markus Moeller wrote:
> To point 2) I would do the password change through Kerberos kpasswd or if 
> you need to do it as an admin I think there is also a function in the MIT 
> library to do so.
> 
> Regards
> Markus
> 
> "Craig Huckabee" <huck at spawar.navy.mil> wrote in message 
> news:43175FA9.9090008 at spawar.navy.mil...
> 
>>Markus,
>>
>>  Two reasons:
>>
>>  1)  We are working towards turning off non-SSL access to our Sun LDAP 
>>servers.
>>
>>  2)  We ran into problems when talking to AD using Perl-LDAP/SASL without 
>>SSL.  IIRC, we couldn't do a password change over a non-SSL port - AD spit 
>>back an error.  Doing everything over SSL cleared up the problems.
>>
>>But, yes, in most cases we could just use one or the other.
>>
>>--Craig
>>
>>
>>Markus Moeller wrote:
>>
>>
>>>Craig,
>>>
>>>you say you use SASL + SSL. As far as I know SASL/GSSAPI can do 
>>>encryption too. What was the reason not to use SASL/GSSAPI with 
>>>encryption. And example is AD, which can be accessed via SASL/GSSAPI with 
>>>encryption.
>>>
>>>Thanks
>>>Markus
>>>
>>>"Craig Huckabee" <huck at spawar.navy.mil> wrote in message 
>>>news:4316DEC8.5060809 at spawar.navy.mil...
>>>
>>>
>>>>Kent Wu wrote:
>>>>
>>>>
>>>>>  So my question is that is it pretty easy to enable Kerberos for SUN 
>>>>>LDAP after installing SEAM? Or can SUN LDAP use other KDC as well?
>>>>
>>>> We use Sun's LDAP server with PADL's GSSAPI plugin - we built our copy 
>>>>against MIT Kerberos 1.3.x and use MIT KDCs.  I think the binary 
>>>>versions they sold previously also use MIT Kerberos.
>>>>
>>>> We now have several processes that regularly use only GSSAPI/SASL over 
>>>>SSL to authenticate and communicate with LDAP.  Works very well.
>>>>
>>>>HTH,
>>>>Craig
>>>>
>>>>________________________________________________
>>>>Kerberos mailing list           Kerberos at mit.edu
>>>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>>>
>>>
>>>
>>>
>>>
>>>________________________________________________
>>>Kerberos mailing list           Kerberos at mit.edu
>>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>>
>>________________________________________________
>>Kerberos mailing list           Kerberos at mit.edu
>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>
> 
> 
> 
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos





More information about the Kerberos mailing list