First you'll note that the standard OD mappings map
CertificateAuthorities to an OU, which doesn't exist in OD by
default so you have to re-do the mappings if you have a standard OD
setup.
Actually it's the certificationAuthority object that takes the OU
objectClass, not the certificateauthorities container itself. Since
the certificationAuthority is just an auxiliary objectClass, it needs
a structural objectClass as well (every object must have at least one
structural objectClass). As far as LDAP is concerned, you could even
use some other structural objectClass (In looking for information
about this, I've found some people use the applicationEntity or
person classes as well.) This is similar to the macosxodconfig object
in cn=config in that it's an OU objectClass with the data stored in
the description attribute.
Now that I think about it, I wonder if Keychain Access is expecting a
specific name for the object and that is why it doesn't display it
(similiar to how you have to use "macosxodconfig" for server-side
mappings).
That's as far as I've ever been able to get, however. Keychain
Access never saw the certs. Although I've been told that even if
they do show up in keychain access, they aren't really "trusted."
As in you have to drag them from the LDAP entry into your local
X509Anchors before they will be treated as a valid certificate.
Well, at least I'm not the only one who hasn't been able to get it
working :-)
--
John Anthony Grigutis
User Support Specialist III
Apple Certified (ACHDS/ACSA)
Indiana University : UITS : STC : Macintosh/Unix Team
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden
This email sent to email@hidden
