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

[Markus Moeller]

Thank you
Markus

"Craig Huckabee" <huck at spawar.navy.mil> wrote in message 
news:43183ECF.6050102 at spawar.navy.mil...
>
>
> 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
>
>
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>