Thank you Markus "Craig Huckabee" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > 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" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> >>>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" <[EMAIL PROTECTED]> wrote in message >>>>news:[EMAIL PROTECTED] >>>> >>>> >>>>>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 [email protected] >>>>>https://mailman.mit.edu/mailman/listinfo/kerberos >>>>> >>>> >>>> >>>> >>>> >>>>________________________________________________ >>>>Kerberos mailing list [email protected] >>>>https://mailman.mit.edu/mailman/listinfo/kerberos >>> >>> >>>________________________________________________ >>>Kerberos mailing list [email protected] >>>https://mailman.mit.edu/mailman/listinfo/kerberos >>> >> >> >> >> >> ________________________________________________ >> Kerberos mailing list [email protected] >> https://mailman.mit.edu/mailman/listinfo/kerberos > > > > ________________________________________________ > Kerberos mailing list [email protected] > https://mailman.mit.edu/mailman/listinfo/kerberos >
________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
