On Wednesday 30 April 2008 16:43, David Robillard wrote:
> > On Wednesday 30 April 2008 11:00, O. Hartmann wrote:
> [ --- 8< --- SNIP! --- 8< --- ]
> > It's true that an object can only belong to one structural class
> > (although it can belong to many auxiliary classes).
> > I use the auxiliary class extensibleObject, which allows you to add any
> > attribute to an LDAP object. My user accounts have three object classes:
> > inetOrgPerson (the structural class), posixAccount and extensibleObject.
> > The rules for the first two are still enforced, but I am able to add the
> > Host: attribute.
> > Jonathan
> That sounds very interesting Jonathan. Could you please share with us
> the complete LDIF data used to create such a user?
This is live from my LDAP server:
# jfm, group, hst.org.za
# jfm, people, hst.org.za
cn: Jonathan McKeown
mail: [EMAIL PROTECTED]
There is, of course, also a userPassword attribute in the user account. (You
didn't expect me to show you that, did you?!)
Using posixGroup, the attribute for adding additional members to a group is
There's a bit more to getting this all working: configuring slapd.conf with
appropriate schemas, installing and configuring pam_ldap and nss_ldap, and
setting up PAM correctly. I can go into excruciating detail if you like...
My only irritation is that although passwd(1) in 6.3 has the code within it to
allow it to be controlled by PAM, it's all currently diked out, so that you
can't use passwd(1) transparently with LDAP users. (As far as I know this
hasn't changed in 7.0).
inetOrgPerson gives you a huge number of optional fields for other
information, up to and including a JPEG photo. It inherits from
organizationalPerson which inherits from person, so you need to combine all
three sets of attributes to get the complete spec for inetOrgPerson (note the
only MUST attributes are sn and cn from person):
DESC 'RFC2798: Internet Organizational Person'
MAY ( audio $ businessCategory $ carLicense $ departmentNumber $
displayName $ employeeNumber $ employeeType $ givenName $
homePhone $ homePostalAddress $ initials $ jpegPhoto $
labeledURI $ mail $ manager $ mobile $ o $ pager $
photo $ roomNumber $ secretary $ uid $ userCertificate $
x500uniqueIdentifier $ preferredLanguage $
userSMIMECertificate $ userPKCS12 )
DESC 'RFC2256: an organizational person'
MAY ( title $ x121Address $ registeredAddress $
preferredDeliveryMethod $ telexNumber $
teletexTerminalIdentifier $ telephoneNumber $
internationaliSDNNumber $ facsimileTelephoneNumber $
street $ postOfficeBox $ postalCode $
postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l )
DESC 'RFC2256: a person'
SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description )
We're hardly using any of these, but it seemed to make more sense to build it
in, in case.
email@example.com mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"