Gary Winiger wrote: > That's fine (except the ldap server part). I just wanted to ensure > it was clearly stated in the case. Yes we could do the work, > but until Duckwater it's ETOOHARD for the benefit. Now, for the > ldap server, the point is not to make iPlanet DS into the account > authority, but to use the Lightweight Directory Server Protocol > as a name service. The two are definitely not equivalent. Foisting > LDAP bind on a customer who merely wants a modern name service > seems just wrong. Indeed LDAP bind is not on the horizon for > any evaluation. iPlanet DS as a name service is what's being > evaluated (and ABICT is something many CUs have asked for).
Personally I'd prefer Kerberos be the authentication authority rather than LDAP but that can be doing using LDAP bind via SASL and GSS-API. Personally I think we are making a big mistake by not doing LDAP bind in the evaluation. Using LDAP and doing crypt/strcmp is weaker security even when LDAP is being protected by SSL, than an LDAP bind. >>> Additionally, I asked if __unix__ was going to be deprecated. >> It is implicitly deprecated by a) not being the CRYPT_DEFAULT algorithm >> and b) not being listed in CRYPT_ALGORITHMS_ALLOW. Only one of >> CRYPT_ALGORITHMS_ALLOW or CRYPT_ALGORITHMS_DEPRECATE are used at anyone >> time. Since '5' (crypt_sha256) will be listed in CRYPT_ALGORITHMS_ALLOW >> and it will be CRYPT_DEFAULT that means yes __unix__ is an algorithm is >> effectively deprecated. > > You're the expert here. But, that's not what I recall. What > I recall is if __unix__ is not depricated and my current PW > hash is crypt_unix(5), that will be preserved when I change > passwords. Correct. > I've not tested it on a recent SNV build, that's > just my recollection. Not being on CRYPT_ALGORITHMS_ALLOW is equivalent to being on CRYPT_ALGORITHMS_DEPRECATE. > Any how I'd vote for __unix__ to be depricated and for us to That was already in the proposal, it is implicit in CRYPT_DEFAULT being changed since CRYPT_ALGORITHMS_ALLOW does NOT contain __unix__. > P.S. I forget why we didn't/couldn't supply a patch for S8 to do flexible > crypt Resources. It would be possible. -- Darren J Moffat
