Jump to: navigation, search

FreeIPAv2:DS Design Summary

FreeIPAv2 Development Documentation

Please note that this content was made during FreeIPAv2 development and it may no longer be relevant for current versions of FreeIPA. We left the content here for study and archaeological purposes.

Please check our Documentation for a recent list of topics.

Current pages summarizes earlier attempts to define objects in the DS that will represent different concepts.

Entry Identification and Naming

Each entry in the DS has to have an attribute that can be used to differentiate it from another entry. This attribute or combination of attributes will be used as a DN for the entry. Sometimes it is much more convenient to have one unique attribute that differentiates the entries and never changes over the time. We considered several approaches to this problem. Sometimes the CN can be used as DN. But names tend to change. CNs would work OK if there are no child records of the entry that uses name as part of DN. If there are child entries the changes to DN of the parent entry are not allowed. This is the limitation of the directory server. The change to CN if the CN is used as part of the DN would require MODRDN operation. To avoid the need for this and decouple names and unique identification of the entries we will use the new attribute:

  attributeType ( 2.16.840.1.113730.3.8.3.TBD  
    NAME 'ipaUniqueID' 
    DESC 'Unique identifier' 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
    X-ORIGIN 'IPA v2' )


This attribute will contain a unique ID of the entry. The name in this case becomes just another attribute that can be changed at will. There is a similar attribute in the DS. It is named nsUniqueID. This attribute contains GUID that is assigned by the DS automatically when record is created. This attribute can be used as part of the DN but since it is not known in advance one would have to create an entry first and then to change the DN to switch it to use nsUniqueID. We rejected such approach and decided that we will use a different attribute and generate the value for it in advance before inserting an entry.

The GUID is generated using the python uuid module. We will use uuid.uuid1() to generate a GUID from a host ID, sequence number, and the current time.

The CN being a part of the object will provide the way of naming object in a human readable form. It is convenient in UI and especially in CLI when the object needs to be selected for modification or deletion. Unfortunately it is hard to make sure that the value of the CN is unique. Even if we use the special DS plugin that enforces uniqueness for the attribute it would not be possible to enforce the uniqueness of the values in multi master replication environment. So the goal of enforcing 100% uniqueness is not achievable. Since it is not possible to enforce the uniqueness of the names on the back end we will check the uniqueness of the operation in the management plugin (better than nothing). This will leave some room for the advanced administrators to directly manipulate the DS using LDAP tools and create entries with duplicate CNs. Potentially if the administrator creates such a situation he would have to clean it manually using the LDAP tools. The management plugin(s) would have to be written in such a way that if it expected one entry but got more than one in the result set, it will either always deal with the first entry or will return an error. This will be decided at the implementation phase.

There have been a discussion about using a single valued attribute for the naming instead of CN that can be multi-valued. There is currently no reason of doing it. Yes it would help a bit by enforcing that an entry can have only one name. But it does not solve the whole problem. We will have some checking implemented in the management plugin(s) anyways so we might very well check for single value of CNs too. If administrator uses direct LDAP tools and creates entries with more than one CN he would have to clean the ambiguity later.

We might reconsider switching to a specific uniqueName single valued attribute instead of CN if we find more compelling reasons of doing so during implementation phase.

Basic Objects (Accounts)

User

During the migration to IPA v2 the following auxiliary object class will be applied to all entries that can act as kerberos principals in the system.

objectClasses ( 2.16.840.1.113719.1.301.6.16.1 
  NAME 'krbTicketPolicyAux' 
  AUXILIARY 
  MAY ( krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge ) 
  X-ORIGIN 'user defined' ) 

This object class is already applied to the service entries by default. It will be a part of the host entries as described below in the next section.
The entries to update will be selected using the following search criteria:

 (&((objectClass=krbPrincipalAux)(!(objectClass=krbTicketPolicyAux))))   

It is expected that only user records will be updated by this operation. Moving forward the users will be automatically created with this object class applied. This does not mean that the attributes that come with this class will be automatically created. The whole purpose of this object class is to allow overriding the default behavior on per principal basis.


For future use the following object class will also be applied to all user entries during migration and creation:

  objectClass ( 2.5.6.21 NAME 'pkiUser'
             DESC 'X.509 PKI User'
             SUP top AUXILIARY
             MAY userCertificate )

As a result user entries in IPA v2 will look like this:

  # ssupport, users, accounts, dc=...
  dn: uid=ssupport,cn=users,cn=accounts,dc=...
  telephoneNumber: 1-999-999-9999
  cn: Sam Supporty
  labeledUri: www.samsupport.com
  street: One Somewhereville Rd
  homeDirectory: /home/ssupport
  employeeType: Bee
  uid: ssupport
  title: Engineer
  facsimileTelephoneNumber: 1-999-999-9980
  loginShell: /bin/sh
  mail: ssupport@ipa.com
  displayName: Sam Supporty
  description: Great Person
  businessCategory: Tag1, Tag2, Tag3
  roomNumber: Apt Z
  carLicense: 1092HI
  postalCode: 01701
  krbPrincipalName: ssupport@...
  givenName: Sam
  pager: 1-999-999-9960
  objectClass: top
  objectClass: person
  objectClass: organizationalPerson
  objectClass: inetOrgPerson
  objectClass: inetUser
  objectClass: posixAccount
  objectClass: krbPrincipalAux
  objectClass: radiusprofile
  objectClass: krbTicketPolicyAux
  objectClass: pkiUser
  l: Nowherough
  st: AH
  mobile: 1-999-999-9970
  gidNumber: 1002
  gecos: 1-800-helpdesk
  sn: Supporty
  ou: Support
  homePhone: 1-666-666-7777
  initials: SS
  uidNumber: 1100
  memberOf: cn=ipausers,cn=groups,cn=accounts,dc=...
  memberOf: cn=support,cn=groups,cn=accounts,dc=...
  krbLastPwdChange: 20080505191739Z
  krbPasswordExpiration: 20080505191739Z
  manager: uid=ssupport,cn=users,cn=accounts,dc=...
  secretary: uid=ssupport,cn=users,cn=accounts,dc=...

Host

As it was mentioned on the FreeIPAv2:Concepts and Objects page we would want to express the following attributes:

Attribute Meaning and use Suggested Attribute Comes from Comment
Fully qualified hostname Name of the host used in UI/CLI to identify the host commonName device or nsHost Potentially from nsHost
Kerberos principal This a kerberos name of the host krbPrincipalName krbPrincipalAux
Kerberos keytab Key the host will use to authenticate against IPA krbPrincipalKey krbPrincipalAux
Kerberos key expiration Expiration information for the kerberos keytab krbPrincipalExpiration krbPrincipalAux
User password Standard DS hash of password used for the bulk enrollment userPassword or new attribute. <TBD> userPassword might trigger
additional behavior in plugins.
This might not be the right
way to go.
Unique identifier It is assigned to the host at the moment of the enrollment or record creation. nsuniqueid <Any>
CN (or DN) if the administrator who enrolled the machine If the machine was enrolled manually enrolledBy <new> There is no such attribute yet. For beter referential integrity we will use DN, not cn.
Version of the client installed on the machine This version is maintained and updated by the client ipaClientVersion <new> There is no such attribute yet
OS version This attribute is maintained by the client nsOsVersion nsHost
Comment This field will be used by the administrator to add comment about the purpose of the machine description nsHost
Certificate This field will be used to store machine certificate userCertificate pkiUser

The host entry will represented by the following objectClasses:

  • nsHost – structural class
  • krbPrincipalAux – auxiliary class that holds all necessary kerberos attributes
  • ipaHost – auxiliary class that will hold specific attributes that IPA cases about.
  • pkiUser - to store certificates for the host

It is not clear how we should deal with the password in the host entry. We have two options:

  • Use userPassword attribute. In this case there might be some unexpected behavior in the password management plugin.
  • Create a new attribute for the password. In this case we would have to deal with new ACI's for this attribute.

The solution is to start using the userPassword attribute and if we hit the wall define a new attribute for enrollment password.

In addition to the object classes mentioned above we will add an auxiliary class krbTicketPolicyAux.

objectClasses: ( 2.16.840.1.113719.1.301.6.16.1 
  NAME 'krbTicketPolicyAux' 
  AUXILIARY 
  MAY ( krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge ) 
  X-ORIGIN 'user defined' ) 

This class would allow controlling kerberos ticket renewal policies on per host basis if we decide to implement it in future.

New Attributes

  attributeType ( 2.16.840.1.113730.3.8.3.TBD  
    NAME 'ipaClientVersion' 
    DESC 'Text string describing client version of the IPA software installed' 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
    X-ORIGIN 'IPA v2' )
  
  attributeType ( 2.16.840.1.113730.3.8.3.TBD  
    NAME 'enrolledBy' 
    DESC 'DN of administrator who performed manual enrollment of the host' 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12  
    X-ORIGIN 'IPA v2' )

Next attribute is defined here in case we would not be able to reuse userPassword.

  attributeType ( 2.16.840.1.113730.3.8.3.TBD  
    NAME 'enrollmentPwd' 
    DESC 'Password used to bulk enroll machines' 
    EQUALITY octetStringMatch 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128}
    X-ORIGIN 'IPA v2' )

Other Attributes (for reference)

  attributeType ( nsHostLocation-oid 
    NAME 'nsHostLocation' 
    DESC 'Netscape defined attribute type' 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
    X-ORIGIN 'Netscape')
  
  attributeType ( nsHardwarePlatform-oid 
    NAME 'nsHardwarePlatform' 
    DESC 'Netscape defined attribute type' 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
    X-ORIGIN 'Netscape' )
  
  attributeType ( nsOsVersion-oid 
    NAME 'nsOsVersion' 
    DESC 'Netscape defined attribute type' 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
    X-ORIGIN 'Netscape' )

Object Classes

Standard object class for hosts defined by Netscape.

  objectclass ( nsHost-oid 
    NAME 'nsHost' 
    DESC 'Netscape defined objectclass' 
    SUP top STRUCTURAL 
    MUST cn
    MAY ( serverHostName $ description $ l $ nsHostLocation $ nsHardwarePlatform $ nsOsVersion ) 
    X-ORIGIN 'Netscape' )

Kerberos related auxiliary class:

  objectclass ( 2.16.840.1.113719.1.301.6.8.1 
    NAME 'krbPrincipalAux' 
    AUXILIARY 
    MAY ( krbPrincipalName $ krbUPEnabled $ krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $ krbPasswordExpiration $ krbPwdPolicyReference $ 
          krbPrincipalType $ krbPwdHistory $ krbLastPwdChange $ krbPrincipalAliases $ krbLastSuccessfulAuth $ krbLastFailedAuth $ krbLoginFailedCount $ krbExtraData ) 
    X-ORIGIN 'user defined' )
  

Kerberos ticket policies class:

  objectClass ( 2.16.840.1.113719.1.301.6.16.1 
    NAME 'krbTicketPolicyAux' 
    AUXILIARY 
    MAY ( krbTicketFlags $ krbMaxTicketLife $ krbMaxRenewableAge ) 
    X-ORIGIN 'user defined' ) 

CA Certificate storage class:

  objectClass ( 2.5.6.21 NAME 'pkiUser'
            DESC 'X.509 PKI User'
            SUP top AUXILIARY
            MAY userCertificate )

New IPA related auxiliary class that will hold the IPA specific information:

  objectclass ( 2.16.840.1.113730.3.8.4.TBD 
    NAME 'ipaHost' 
    AUXILIARY 
    MAY ( userPassword $ ipaClientVersion $ enrolledBy) 
    X-ORIGIN 'IPA v2' )

In case the userPassword attribute approach does not work out the object class will be altered like this:

  objectclass ( 2.16.840.1.113730.3.8.4.TBD 
    NAME 'ipaHost' 
    AUXILIARY 
    MAY ( enrollmentPwd $ ipaClientVersion $ enrolledBy) 
    X-ORIGIN 'IPA v2' )

Example

  dn: cn=ipa-client.ipa-realm.com, cn=computers, cn=accounts, ...
  objectClass: nsHost
  objectClass: krbPrincipalAux
  objectClass: krbTicketPolicyAux
  objectClass: ipaHost
  objectClass: pkiUser
  cn: ipa-client.ipa-realm.com 
  serverHostName: ipa-client 
  description: IPA test client machine
  localityname: Westford, MA
  nsHostLocation: Development Lab
  nsHardwarePlatform: Lenovo T61
  nsOsVersion: Red Hat Enterprise Linux 5.3 
  krbPrincipalName: host/ipa-client.ipa-realm.com@ipa-realm.com
  userPassword: XYZZY
  ipaClientVersion: 2.1 
  enrolledBy: cn=ipa-admin,cn=users,cn=accounts,...
  userCertificate: <cert data> 

Searching for Hosts

Host can be viewed from the perspective of kerberos authentication to be a special kind of service entry.
The search that kerberos server performs when it is looking for a kerberos principals should include users, services and now hosts.

It was identified that in v1.x the function that looks up services is assuming krbPrincipal object class.
That should change. The entities that can be used in the kerberos authentication will have krbPrincipalAux object class.
This is the main criteria that should be used to find kerberos principals.
If the users shall be excluded but hosts and services included the search should look for krbPrincipalAux and exclude posixAccount

  (&(objectclass = krbPrincipalAux)(!(objectclass=posixAccount)))

The search for service will be fixed to lookup services by a new object class that will be created for services. See details below.

Bulk Deployment of Hosts

When the hosts are created for the bulk enrollment and one time enrollment password is set in the userPassword attribute the kerberos attributes and krbPrincipalAux object class won't be initially set. The enrollment procedure after authenticating with userPassword will remove the password attribute, generate kerberos attributes and apply the krbPrincipalAux object class to the host entry.

This may be done via a DS plugin that accepts a special request from ipa-getkeytab. This way we aren't relying on client code to set things properly, particularly removing the userPassword attribute.

If ipa-getkeytab is modified to be able to do a simple bind then it could authenticate to the LDAP server, issue an LDAP extended operation provided by this plugin. This plugin will then remove the userPassword attribute, update objectClass and set krbPrincipalName. If successful then ipa-getkeytab would do its keytab operation.

The result would be a local keytab that could be used for subsequent operations.

Host Renames

IPA v2 will not support in place host renames. To rename a host one would have to:

  • Un-enroll it (all locally cached configuration data is removed)
  • Remove it from IPA (entry is removed from the back end)
  • Rename host
  • Enroll new host with IPA as if it is a new host

Services

A new object class will be created and applied to services during migration so that services can be easily identified and searched.

  objectclass ( 2.16.840.1.113730.3.8.4.TBD 
    NAME 'ipaService' 
    DESC 'IPA service objectclass' 
    AUXILIARY 
    X-ORIGIN 'IPA v2' )

The searches in the XML-RPC layer will be updated to leverage this object class.

Also in v2 the service entries might also be used to store certificate for this service. To be able to this we will use pkiUser auxiliary objectClass. For more details about his class see next section.

To be able to use certificates with services the following object class will be created during migration from v1.x to v2 and also each time an entry is created. It is needed so that we can store certificate in the service entry:

 objectClass ( 2.5.6.21 NAME 'pkiUser'
            DESC 'X.509 PKI User'
            SUP top AUXILIARY
            MAY userCertificate )

Groups of Hosts and Users

Since group of host has similar properties as group of users it should leverage same or similar object classes as group of users.

The following is the example of the group of users named “Support”.

  dn:cn=Support,cn=groups,cn=accounts,dc=...
  objectClass: top
  objectClass: groupofnames
  objectClass: posixGroup
  objectClass: inetUser
  cn: Support
  description: Support Group
  gidNumber: 1100
  member: uid=ssupport,cn=users,cn=accounts,dc=...

In this example one sees that the group of users leverages base structural class groupofnames

  objectclass ( 2.5.6.9 
    NAME 'groupOfNames' 
    DESC 'Standard LDAP objectclass' 
    SUP top STRUCTURAL 
    MUST cn 
    MAY ( member $ businessCategory $ description $ o $ ou $ owner $ seeAlso ) 
    X-ORIGIN 'RFC 2256' )

On top of it it uses posix attributes that come with posixGroup.

  objectclass ( 1.3.6.1.1.1.2.2 
    NAME 'posixGroup' 
    DESC 'Standard LDAP objectclass' 
    SUP top STRUCTURAL 
    MUST ( cn $ gidNumber ) 
    MAY ( userPassword $ memberUid $ description ) 
    X-ORIGIN 'RFC 2307' )

The inetUser object class is used to provide the nesting capability.

  objectclass ( 2.16.840.1.113730.3.2.130 
    NAME 'inetUser' 
    DESC 'Auxiliary class which must be present in an entry for delivery of subscriber services' 
    SUP top AUXILIARY 
    MAY ( uid $ inetUserStatus $ inetUserHttpURL $ userPassword $ memberOf ) 
    X-ORIGIN 'Netscape subscriber interoperability' )


As one can see the choice of the object classes to represent the groups in IPA is not very clean since inetUser for example brings a lot of attributes that do not make sense in the context of the group. Another issue is that posixGroup and groupOfnames are both structural objects. This is not a good object design and violates the schema design rules though DS does not enforce them.

We evaluated several different approaches and decided that we will clean the schema for the user group a bit and use a new generic structural object class for the collections of objects that can nest each other. The new class will be based on the groupOfNames object class and look like this:

  objectclass ( 2.16.840.1.113730.3.8.4.TBD 
    NAME 'nestedGroup' 
    DESC 'Group that supports nesting' 
    SUP groupOfNames STRUCTURAL 
    MAY  memberOf  
    X-ORIGIN 'IPA v2' )

Though groups of users and groups of hosts will be stored in different sections of the tree and we can potentially use one and the same object class for them we will also create specific object classes to differentiate them so it would be easier to perform searches.

  objectclass ( 2.16.840.1.113730.3.8.4.TBD 
    NAME 'ipaUserGroup' 
    DESC 'IPA user group object class' 
    SUP nestedGroup STRUCTURAL 
    X-ORIGIN 'IPA v2' )
  objectclass ( 2.16.840.1.113730.3.8.4.TBD 
    NAME 'ipaHostGroup' 
    DESC 'IPA host group object class' 
    SUP nestedGroup STRUCTURAL 
    X-ORIGIN 'IPA v2' )

Since the objects derive from each other creating ipaHostGroup entry will imply that it is object of the nestedGroup and groupOfNames classes.

The user groups shall from now on be created using ipaUserGroup object class. For groups that will be migrated from previous version of IPA the ipaUserGroup object class will be applied. There is a bit of collision since the ipaUseGroup is a structural class but DS does not enforce this. So we will use this back door to correct the structure of the user groups for future.

Other objects classes that will represent collections of other objects that support nesting can be derived from the common nestedGroup object class.

In addition to the introduction of the new classes we will decouple user group object class from the posixGroup. Starting IPA v2 the groups will be created as just ipaUserGroups. The posixGroup object class and value for gidNumber will be added if the group is created or modified to be a posix group. Unfortunately posixGroup is a structural class but fortunately DS does not restrict adding one structural class on top of another

Example of the new user group object (with posix group):

  dn:cn=Support,cn=groups,cn=accounts,dc=...
  objectClass: top
  objectClass: groupofnames
  objectClass: posixGroup
  objectClass: nestedGroup
  objectClass: ipaUserGroup
  cn: Support
  description: Support Group
  gidNumber: 1100
  member: uid=ssupport,cn=users,cn=accounts,dc=...
  memberof:cn=northamerica,cn=groups,cn=accounts,dc=...

Example of the new user group object (without posix group):

  dn:cn=eng,cn=groups,cn=accounts,dc=...
  objectClass: top
  objectClass: groupofnames
  objectClass: nestedGroup
  objectClass: ipaUserGroup
  cn: eng
  description: Engineering Group
  member: uid=someone,cn=users,cn=accounts,dc=...
  memberof:cn=eng-northamerica,cn=groups,cn=accounts,dc=...

Example of the new host group object:

  dn:cn=myhosts,cn=computergroups,cn=accounts,dc=...
  objectClass: top
  objectClass: groupofnames
  objectClass: nestedGroup
  objectClass: ipaHostGroup
  cn: myhosts
  description: my host group
  member: cn=ipa-client.ipa-realm.com,cn=computers,cn=accounts,dc=...
  memberof:cn=Westford,cn=computergroups,cn=accounts,dc=...

Since we plan to use the already existing groupOfNames objectClass we will not use the ipaUniqueID attribute with user and host groups. To rename user or host group object one would have to use MODRDN operation.

Association of Different Entities

Association

One of the basic objects that will be used in the IPA to represent different combinations of users and hosts is named “association”. It will be the base for multiple other objects that represent netgroups, user roles, host based access control rules and may be other entities in the future. The main purpose of this object is to define association between set of users and hosts. Users can be expressed as groups, individual users or all. Hosts can be expressed via groups of hosts, individual hosts or all. The association defines the relation between set of users and set of hosts. For example in case of netgroups it is collection of users and collection of hosts that constitute the netgroup. In case of the host base access control it is the collection of users who can or depending on type of rule can't access the set of hosts.

Association Attributes

The first attribute of the association object is the reference to a "user". When we talk about a "user" we should not imply that it is a real person. The "user" can be a real person but it also potentially be any authenticated kerberos entity including hosts and services or any other objects that we think might be of a value in future. This is the multi value attribute.

 attributeType ( 2.16.840.1.113730.3.8.3.TBD 
    NAME 'memberUser' 
    DESC 'Reference to a principal that performs an action (usually user).' 
    SUP distinguishedName 
    EQUALITY distinguishedNameMatch 
    ORDERING distinguishedNameMatch 
    SUBSTR distinguishedNameMatch 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 
    X-ORIGIN 'IPA v2')

Sometimes we would need to reference a category of "users" that can't be easily expressed by the groups mechanism. In IPA v2 we envision only one such value "All" but in future we anticipate more of those. For example "All authenticated users", "All users in this realm", "All users in known IPA realms", "All external users" etc. To express this concept we will use a multi value string attribute.

 attributeType ( 2.16.840.1.113730.3.8.3.TBD
   NAME 'userCategory' 
   DESC 'Additional classification for users' 
   EQUALITY caseIgnoreMatch 
   ORDERING caseIgnoreMatch 
   SUBSTR caseIgnoreSubstringsMatch 
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
   X-ORIGIN 'IPA v2')

The userCategory attribute should be handled by the client using the following logic. The client should consult this attribute first before looking at the memberUser attribute. If this attribute is present and equal to "all" then the association is applicable to all users. In this case the value of the memberUser attribute should be ignored. If the value of the attribute is not "all" the client should consult the value of the memberUser attribute. If the memberUser attribute is not present the rule is not applicable to any user. Such approach would allow adding new values to the userCategory without breaking old client logic.

See specific comments about the client behavior in case the rule can't be properly interpreted in the section talking about the objects derived from the association.

Similar pair of attributes will be used to refer to hosts:

 attributeType ( 2.16.840.1.113730.3.8.3.TBD 
    NAME 'memberHost' 
    DESC 'Reference to a device where the operation takes place (usually host).' 
    SUP distinguishedName 
    EQUALITY distinguishedNameMatch 
    ORDERING distinguishedNameMatch 
    SUBSTR distinguishedNameMatch 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 
    X-ORIGIN 'IPA v2')

 attributeType ( 2.16.840.1.113730.3.8.3.TBD
   NAME 'hostCategory' 
   DESC 'Additional classification for hosts' 
   EQUALITY caseIgnoreMatch 
   ORDERING caseIgnoreMatch 
   SUBSTR caseIgnoreSubstringsMatch 
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
   X-ORIGIN 'IPA v2')

In IPA v2 the memberHost will point only to host objects but in future we anticipate that we would need to differentiate between different kinds of hosts: virtual hosts, virtual guests, clusters, network devices etc. We plan to use memberHost attribute to reference all these objects in future.

The hostCategory attribute should be handled by the client using the following logic. The client should consult this attribute first before looking at the memberHost attribute. If this attribute is present and equal to "all" then the association is applicable to all hosts. In this case the value of the memberHost attribute should be ignored. If the value of the attribute is not "all" the client should consult the value of the memberHost attribute. If the memberHost attribute is not present the rule is not applicable to any host.

See specific comments about the client behavior in case the rule can't be properly interpreted in the section talking about the objects derived from the association.

In addition to the basic attributes we will have a following Boolean attribute to allow enable/disable functionality:

  attributeType ( 2.16.840.1.113730.3.8.3.TBD 
    NAME 'ipaEnabledFlag' 
    DESC 'The flag to show if the association is active or should be ignored' 
    EQUALITY booleanMatch 
    ORDERING booleanMatch 
    SUBSTR booleanMatch 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 
    SINGLE-VALUE
    X-ORIGIN 'IPA v2')

In many cases it would be beneficial to also have a cn attribute so that the rule or association can be given a name for easier management. Having a distinguished unique name within the class of associations would be beneficial so I propose to have cn as a mandatory attribute. This would allow more user friendly UI and CLI object management. For the identification of the association objects and its derivatives we will use ipaUniqueID attribute.

Association Object

The following object class represents the ipaAssociation. The description attribute is added to store comments.

  objectclass ( 2.16.840.1.113730.3.8.4.TBD
    NAME 'ipaAssociation' 
    ABSTRACT 
    MUST ( ipaUniqueID $ cn )
    MAY ( memberUser $ userCategory $ memberHost $ hostCategory $ ipaEnabledFlag $ description ) 
    X-ORIGIN 'IPA v2' )

The association is created as an abstract class since it contains a minimal set of common attributes other classes will use.

Example

There is no example of the association object since it is an abstract class and thus can't be instantiated.

Derived Objects

The following objects will derive from the association:

  • Host based access control (HBAC) rule
  • Netgroup
  • Relation (a part of the role base model, it is used to map identities to roles)

The first two derived objects are covered in this part of the page. The "Relation" is covered in the part of the page that talks about policy related objects.

HBAC object

Object Class

The object itself is structured as follows:

  objectClasses ( 2.16.840.1.113730.3.8.4.7
    NAME 'ipaHBACRule' 
    SUP ipaAssociation 
    STRUCTURAL
    MUST accessRuleType
    MAY ( serviceCategory $ memberService $ sourceHost $ sourceHostCategory $ externalHost $ accessTime )
    X-ORIGIN 'IPA v2' )


HBAC rules need to express the following concepts:

  • User — the user who is trying to access the target machine
  • Target machine — the machine that the user is trying to access
  • Service (access method) — the service that the user is using to try to access the target machine
  • Source machine — the machine from which the user is trying to access the target machine
  • Time of day — the time of day when the HBAC rule applies
  • Type of rule — allow or deny

Attributes

The HBAC rule is a derived object from the IPA Association Object. The association is created as an abstract class because it contains a minimal set of common attributes that other classes will use. The CN is used to name HBAC rules for convenience of management. The ipaEnabledFlag allows enabling and disabling rules without deleting them. The ipaUniqueID will be used as a unique identifier and part of the DN.

The following attributes are derived from the ipaAssociation, but are only ever used as part of HBAC rules:

serviceCategory

This attribute specifies the services to which the rule applies. Only a specific value, "all", is supported in IPA v2.

  attributeTypes: (2.16.840.1.113730.3.8.3.20
    NAME 'serviceCategory'
    DESC 'Additional classification for services.'
    EQUALITY caseIgnoreMatch
    ORDERING caseIgnoreMatch
    SUBSTR caseIgnoreSubstringsMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    X-ORIGIN 'IPA v2' )

memberService

This attribute stores the name of the service the user is using to attempt access. This is a DN pointing to an HBAC service entry.

  attributeTypes: (2.16.840.1.113730.3.8.3.21
    NAME 'memberService'
    DESC 'Reference to the pam service of this operation.'
    SUP distinguishedName
    EQUALITY distinguishedNameMatch
    ORDERING distinguishedNameMatch
    SUBSTR distinguishedNameMatch
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    X-ORIGIN 'IPA v2' )

In addition to the attributes presented by the ipaAssociation class, HBAC rules can make use of the following attributes:

sourceHost

This attribute contains information about the host from which the user is logging in. This attribute is a twin of the memberHost attribute so it is derived from it.

  attributeTypes ( 2.16.840.1.113730.3.8.3.11 
    NAME 'sourceHost' 
    DESC 'Link to the host or group of hosts.' 
    SUP memberHost     
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
    X-ORIGIN 'IPA v2')

externalHost

There might be an argument that the source hosts are not a part of the managed environment. For example, access should be granted from Windows machine. The externalHost attribute addresses this scenario:

  attributeTypes ( 2.16.840.1.113730.3.8.3.12 
    NAME 'externalHost' 
    DESC 'Multivalue string attribute that allows storing host names.' 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
    X-ORIGIN 'IPA v2' )

sourceHostCategory

This attribute is also a twin of an already existing attribute, hostCategory. It is used to denote if the login is allowed from all the remote hosts or only from a specific category of hosts. Only a specific value, "all" is supported in IPA v2. In future it can be extended to denote "All external hosts", "all hosts with a specific IP mask etc.". The client logic should consult this attribute first before looking at the sourceHost attribute.

If this attribute is present and equal to "all" then the rule is applicable to all source hosts. In this case the value of the sourceHost attribute should be ignored. If the value of the attribute is not "all" then the client should consult the value of the sourceHost attribute. If the sourceHost attribute is not present it should check the value of the externalHost attribute. If none are present then the rule is not applicable to any source host.

  attributeTypes ( 2.16.840.1.113730.3.8.3.13
    NAME 'sourceHostCategory' 
    DESC 'Additional classification for hosts.' 
    EQUALITY caseIgnoreMatch 
    ORDERING caseIgnoreMatch 
    SUBSTR caseIgnoreSubstringsMatch 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    X-ORIGIN 'IPA v2')

accessRuleType

This attribute specifies the type of the HBAC rule. It can have a value of either "allow" or "deny". If any other value is present the client should assume it is a deny rule.

  attributeTypes ( 2.16.840.1.113730.3.8.3.14 
    NAME 'accessRuleType' 
    DESC 'The flag to represent if it is allow or deny rule.' 
    EQUALITY caseIgnoreMatch 
    ORDERING caseIgnoreMatch 
    SUBSTR caseIgnoreSubstringsMatch 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    X-ORIGIN 'IPA v2')


Expressing Time in a Rule

There are several approaches that can be used to deal with time.

  • One approach is to use binary blob to represent an array of access time buckets
  • Another is to have ranges.

We evaluated the two approaches and decided to go with the approach based on ranges.

Time Attribute

The following attribute is used to store range information:

  attributeTypes ( 2.16.840.1.113730.3.8.3.15  
    NAME 'accessTime' 
    DESC 'Access time' 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
    X-ORIGIN 'IPA v2' )

It is important to acknowledge that this is a multi-valued attribute and that the same rule can have a number of range values. All of these values are retrieved by the client and validated for each HBAC rule. If no value is specified then the caller should assume that the rule always applies.

Grammar

The following grammar describes the format used to express ranges:

timerange = Absolute / Periodic

Absolute = "absolute" WSP generalizedTime WSP "~" WSP generalizedTime 

generalizedTime as defined in RFC 4517 section 3.3.13 but without time zone at the end.

Periodic = "periodic" WSP Yearly / Monthly / Weekly / Daily

Yearly = "yearly" WSP Y-specifier WSP HHMM WSP "~" WSP HHMM 

Monthly = "monthly" WSP M-specifier WSP HHMM WSP "~" WSP HHMM 

Weekly = "weekly" WSP W-specifier WSP HHMM WSP "~" WSP HHMM

Daily = "daily" WSP HHMM WSP "~" WSP HHMM

Y-specifier = Y-month / Y-week / Y-day

Y-month = "month" WSP month-number WSP M-specifier

Y-week = "week" WSP week-of-the-year WSP W-specifier

Y-day = "day" WSP day-of-the-year

M-specifier = M-week / M-day

M-week = "week" WSP week-of-the-month WSP W-specifier

M-day = "day" WSP day-of-the-month

W-specifier = "day" WSP day-of-the-week

month-number = interval 1-12

week-of-the-year = interval 1-52

week-of-the-month = interval 1-6

day-of-the-month = interval 1-31

day-of-the-week = interval 1-7 (or Mon-Sun)

HH = "00" to "23"

MM = "00" to "59"


interval XX-YY = a comma-separated list of items from XX to YY, or dash-separated ranges.

For example, (interval 1-31) 3-7,10,12,15,25-31 with no spaces inside.

This grammar allows the creation of a flexible set of time ranges that include both absolute and periodic date ranges. The dates in the range do not contain any time zone information. Periodic ranges are stored without time zone information in the same format as specified in the UI and the CLI, and are interpreted on the client as a time range in the local machine's time. Absolute ranges do not specify the time zone because absolute time ranges must be specified in UTC. The UI and CLI must convert time stamps entered in local time format during management operations into UTC format. Applications that access LDAP directly for this data must be aware of the rules and assumptions described above.

Examples of Expressing Time Ranges

To express a time range that applies on Saturday and Sunday from 9AM to 1PM EST every second week of every month, local machine time:

  periodic monthly week 2 day Sat,Sun 0900-1300 

To express a time range that applies from midnight, 10th of October, 2008, until midday, 15th of October, 2008, in UTC:

  absolute 20081010000000 ~ 20081015120000


Examples of HBAC Rules

This section provides some examples of straight-forward rules designed to illustrate how to use the available HBAC attributes to provide or restrict access. It does not provide an exhaustive list of the range of possible HBAC rules.

Examples of "Allow" Rules

The following example shows an "allow" rule which allows the user “user01” to access the host “user01-dev” at any time, using any service, and from any host:

 dn: ipaUniqueID=36471a20-cbed-11dd-ad8b-0800200c9a66, cn=hbac,...
 objectClass: top
 objectClass: ipaAssociation
 objectClass: ipaHBACRule
 ipaUniqueID: 36471a20-cbed-11dd-ad8b-0800200c9a66
 accessRuleType: allow
 memberUser: cn=user01,cn=users,cn=accounts,...
 memberHost: cn=user01-dev,cn=computers,cn=accounts,...
 serviceCategory: all
 sourceHostCategory: all

The following example shows an "allow" rule which allows ssh access by the user “user01” and any member of the “Development” group to the host “test.lab.example.com”, and to the group of hosts “VirtGuests”, at any time.

 dn: ipaUniqueID=49af8430-cbed-11dd-ad8b-0800200c9a66, cn=hbac,...
 objectClass: top
 objectClass: ipaAssociation
 objectClass: ipaHBACRule
 ipaUniqueID: 49af8430-cbed-11dd-ad8b-0800200c9a66
 accessRuleType: allow
 memberUser: cn=user01,cn=users,cn=accounts,...
 memberUser: cn=Development,cn=groups,cn=accounts,...
 memberHost: cn=test.lab.example.com,cn=computers,cn=accounts,...
 memberHost: cn=VirtGuests,cn=hostgroups,cn=accounts,...
 memberService: cn=ssh,cn=hbacservices,cn=accounts,...
 sourceHostCategory: all


Examples of "Deny" Rules

The following example shows a "deny" rule which prohibits ssh access by the user “support” and any member of the “Guests” group to the host “helpdesk.lab.example.com”, and to the group of hosts “VirtGuests”, over the weekend in local machine time.

 dn: ipaUniqueID=5560d540-cbed-11dd-ad8b-0800200c9a66, cn=hbac,...
 objectClass: top
 objectClass: ipaAssociation
 objectClass: ipaHBACRule
 ipaUniqueID: 5560d540-cbed-11dd-ad8b-0800200c9a66
 accessRuleType: deny
 memberUser: cn=support,cn=users,cn=accounts,...
 memberUser: cn=Guests,cn=groups,cn=accounts,...
 memberHost: cn=helpdesk.lab.example.com,cn=computers,cn=accounts,...
 memberHost: cn=VirtGuests,cn=hostgroups,cn=accounts,...
 memberService: cn=Remote Services,cn=hbacservicegroups,cn=accounts,...
 accessTime:  periodic weekly day Sat,Sun 0000-2400
 sourceHostCategory: all

The following example shows a "deny" rule which prohibits any telnet access by any user to the group of hosts named "mission-critical" at any time:

 dn: ipaUniqueID=3cddcf00-cbed-11dd-ad8b-0800200c9a66, cn=hbac,...
 objectClass: top
 objectClass: ipaAssociation
 objectClass: ipaHBACRule
 ipaUniqueID: 3cddcf00-cbed-11dd-ad8b-0800200c9a66
 accessRuleType: deny
 userCategory: all
 memberHost: cn=mission-critical,cn=computergroups,cn=accounts,...
 memberService: cn=telnet,cn=hbacservices,cn=accounts,...
 sourceHostCategory: all

Failing to Interpret Access Rules

The situation may arise where a client fails to interpret the rule. This could happen, for example, if in future we add a new type of value to one of the xxxCategory attributes. If you were to add the value "All hosts in external realm B", and implemented a mechanism in the v3 clients to deal with this value, the v2 clients would not know how to process the rule if it were to encounter this value.

Another situation might arise where an administrator used direct LDAP commands to manipulate data and added a rule with a syntactically incorrect time stamp. Other "formatting" or data mismatch cases could also arise. In any of these cases the client should implement the following rule:

  • If it is a deny rule, deny access and log
  • If it is an allow rule, ignore as if it is not applicable

Guidelines for Lookup Logic

The user-related (userCategory, memberUser), host-related (hostCategory, memberHost), and source host-related (sourceHostCategory, sourceHost, externalHost) attributes form groups of attributes that specify sets of users, hosts, and source hosts in the rule. The client should assume that sets of users and hosts are combined from entities that the attributes represent within each group. For example:

  userCategory: all
  memberUser: <some DN>
  
  result: Rule is applicable to "all" and "<some DN>"

This logic allows adding new values other than "all" to the available categories in the future. For example, if in the future the value "all external hosts" is possible for the sourceHostCategory, the following will result:

  sourceHostCategory: all external hosts
  sourceHost: <some DN>
  
  result: Rule is applicable to "all external hosts" and "<some DN>"

Netgroups

The RFC2307bis schema defines nisNetgroup object class to represent netgroups.

  objectClass ( 1.3.6.1.1.1.2.8 
    NAME 'nisNetgroup' 
    DESC 'Standard LDAP object class' 
    SUP top 
    STRUCTURAL 
    MUST cn 
    MAY ( nisNetgroupTriple $ memberNisNetgroup  $ description ) 
    X-ORIGIN 'RFC 2307' ) 
  • nisNetgroupTriple – is a triplet of host-user-domain, e.g. "(charlemagne,peg,dunes.aja.com)".
  • MemberNisNetgroup – is the name of other netgroup to represent nesting, e.g. "kamakiriad".

IPA will contain a special object to represent netgroups. It is done to avoid duplication of information in user, host entries and netgroup's nisNetgroupTriple attribute. According to specification there is no meaning behind the individual user-host pairs so netgroup can and should be represented by collection of hosts and collection of users. Thus the netgroup entry should point to a user entry, group(s) of users or all. It should also be able to point to the host, group(s) of hosts or all hosts. For this purpose the netgroup object will be derived from the ipaAssociation abstract class.
In addition attributes provided by ipaAssociation object the netgroup entry should also be able to specify hosts that are not members of the IPA domain. A new attribute will be added to address this use case.
Also netgroups can nest each other so netgroup entries will have member and memberOf attribute. The plugin that handles referential integrity of group membership attributes will automatically maintain the correct value for memberOf attribute when netgroup is nested into another netgroup.
The domain information will be associated to the netgroup as a whole. There will be a special attribute nisDomainName added for this purpose. If the nisDomainName attribute is not specified then the IPA realm should be automatically assumed. If the customer would need netgroups for different domains he would have to create two different netgroups.

Netgroups Attributes

externalHost is a new multi value string attribute that allows storing host names. It is convenient for specifying hosts that are not directly managed by IPA but which are members of the netgroup. Because values of this attribute are used directly to construct netgroup triples which are seen by client systems, only exact names can be specified. The same attribute is reused in the HBAC rule to hold the names of the external not managed by IPA hosts.

  attributeType ( 2.16.840.1.113730.3.8.3.TBD 
    NAME 'externalHost' 
    DESC 'Multivalue string attribute that allows storing host names.' 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 
    X-ORIGIN 'IPA v2' )

The following attribute is going to hold the value for nisDomain name. If omitted the default IPA domain name should be assumed.

  attributeType ( 2.16.840.1.113730.3.8.3.TBD 
    NAME 'nisDomainName' 
    DESC 'NIS domain name.' 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
    X-ORIGIN 'IPA v2' )

Netgroups Object

The main netgroup object class will look like this (note that it is derived from ipaAssociation so its attributes are implied):

  objectClass ( 2.16.840.1.113730.3.8.4.TBD 
    NAME 'ipaNISNetgroup' 
    DESC 'IPA version of NIS netgroup' 
    SUP ipaAssociation 
    STRUCTURAL 
    MAY ( externalHost $ nisDomainName  $ member $ memberOf ) 
    X-ORIGIN 'IPA v2' ) 

The the netgroups would be stored under cn=ng, cn=alt, ... in the DIT. The “alt” stands for alternative. Later other “alternative” concepts will end up in this hive.

The default configuration object is described later on this page.

Schema Compat Plugin

Since IPA is going to change the schema for netgroups it will break the expectations of the LDAP clients that are relying on the standard LDAP schema for netgroups defined in RFC2307. To avoid this situation we will use the Schema Compatibility plugin. This plugin will synthesize LDAP entries in the standard format in a different part of the tree. The plugin will look at requests targeting “cn=netgroup,cn=compat,...”, read the entries from “cn=ng,cn=alt,...” and supply the client with search results of the nisNetgroup object class. The details of this mechanism can be found in the FreeIPAv2:Schema Compatibility Plug-in Design page.

Examples

This is the example of the 2 netgroups using new IPA schema. One netgroup is nesting another.

  dn: ipaUniqueID=d4453480-cc53-11dd-ad8b-0800200c9a66,cn=ng,cn=accounts,...
  objectclass: top
  objectclass: ipaAssociation
  objectclass: ipaNISNetgroup
  ipaUniqueID: d4453480-cc53-11dd-ad8b-0800200c9a66
  cn: ng1
  memberHost: fqdn=myhost.lab.com,cn=computers,cn=accounts,...
  memberHost: cn=VirtGuests,cn=hostgroups,cn=accounts,...
  memberUser: cn=sss,cn=users,cn=accounts,...
  memberUser: cn=dpal,cn=users,cn=accounts,...
  memberUser: cn=Engineering,cn=groups,cn=accounts,...
  nisDomainName: oldnis.domain.com
  member: cn=ng2,cn=ng,cn=accounts,...
  
  dn: ipaUniqueID=e9257180-cc53-11dd-ad8b-0800200c9a66,cn=ng,cn=accounts,...
  objectclass: top
  objectclass: ipaAssociation
  objectclass: ipaNISNetgroup
  ipaUniqueID: e9257180-cc53-11dd-ad8b-0800200c9a66
  cn: ng2
  externalHost: foo.lab.domain.com
  memberUser: cn=rcrit,cn=users,cn=accounts,...
  memberUser: cn=Support,cn=groups,cn=accounts,...
  nisDomainName: lab.domain.com
  memberOf: cn=ng1,cn=ng,cn=accounts,...


These two entries will be translated into the following virtual entries assuming that:

  • VirtGuests = guest1.vg.com, guest2.vg.com, guest3.vg.com, NestedVirtualGuests
  • NestedVirtualGuests = nvguest1.vg.com, nvguest2.vg.com, nvguest3.vg.com
  • Engineering = dev1, dev2, dev3
  • Support = support1, support2, support3
  dn: cn=ng1,cn=netgroups,cn=accounts,...
  objectclass: top
  objectclass: nisNetgroup
  cn: ng1
  nisNetgroupTriple: (myhost.lab.com,sss,oldnis.domain.com)
  nisNetgroupTriple: (guest1.vg.com,dpal,oldnis.domain.com)
  nisNetgroupTriple: (guest2.vg.com,dev1,oldnis.domain.com) 
  nisNetgroupTriple: (guest3.vg.com,dev2,oldnis.domain.com)
  nisNetgroupTriple: (nvguest1.vg.com,dev3,oldnis.domain.com)
  nisNetgroupTriple: (nvguest2.vg.com,,oldnis.domain.com)
  nisNetgroupTriple: (nvguest3.vg.com,,oldnis.domain.com)
  memberNisNetgroup: ng2
  
  dn: cn=ng2,cn=netgroups,cn=accounts,...
  objectclass: top
  objectclass: nisNetgroup
  cn: ng2
  nisNetgroupTriple: (foo.lab.domain.com,rcrit,lab.domain.com)
  nisNetgroupTriple: (-,support1,lab.domain.com)
  nisNetgroupTriple: (-,support2,lab.domain.com) 
  nisNetgroupTriple: (-,support3,lab.domain.com)

Interpreting Netgroups

The interpretation of the netgroups is susceptible to the similar issues as interpretation of the HBAC rules. But there are several major differences. If we decide to add values to the userCategory or hostCategory attributes other than "all" in future we would have to update the NG plugin too. Since NG plugin is on the server side we would be able to keep them in synch with new values pretty easily. Also there is no plan to implement any client side code that would use native IPA objects rather than 2307bis compliant entries synthesized in the compat sub-tree. If anyone decides to implement use of native IPA netgroup objects in future he would have to define and declare the secure rules about handling the unknown values for the xxxCategory attributes.

Automount

Automount Schema

The following schema is taken from the RFC 2207bis:

  attributeType ( 1.3.6.1.1.1.1.31 
    NAME 'automountMapName'
    DESC 'automount Map Name'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE
    X-ORIGIN 'RFC 2307bis' )
  
  attributeType ( 1.3.6.1.1.1.1.32 
    NAME 'automountKey'
    DESC 'Automount Key value'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE
    X-ORIGIN 'RFC 2307bis' )
  
  attributeType ( 1.3.6.1.1.1.1.33 
    NAME 'automountInformation'
    DESC 'Automount information'
    EQUALITY caseExactIA5Match
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE
    X-ORIGIN 'RFC 2307bis' )
  
  objectClass ( 1.3.6.1.1.1.2.16 
    NAME 'automountMap'
    DESC 'Automount Map information' SUP top
    STRUCTURAL MUST automountMapName MAY description
    X-ORIGIN 'RFC 2307bis' )
  
  objectClass ( 1.3.6.1.1.1.2.17 
    NAME 'automount'
    DESC 'Automount information' SUP top STRUCTURAL
    MUST ( automountKey $ automountInformation ) MAY description
    X-ORIGIN 'RFC 2307bis' )

Examples

Direct Map

Adding a direct map "auto.direct".

  dn: automountkey=/-,automountmapname=auto.master,cn=automount,dc=example,dc=com
  objectClass: automount
  automountKey: '/-'
  automountInformation: auto.direct
  
  automountmapname=auto.direct,cn=automount,dc=example,dc=com
  objectClass: automountMap
  automountMapName: auto.direct

To add a mount to this direct map for the directory /share you'd add:

  dn: automountkey=/share,automountmapname=auto.direct,cn=automount,dc=example,dc=com
  objectClass: automount
  automountKey: /share
  automountInformation: nfsserver.example.com:/share

Indirect Map

Here is an example of an indirect map for /usr/man. We provide one map, /usr/man/man1.

These three entries provide:

  • A new automount map named auto.man
  • Adds auto.man to auto.master on the mount point /usr/man
  • Adds an indirect mount of man1 to auto.man
  dn: automountmapname=auto.man,cn=automount,dc=example,dc=com
  objectClass: automountMap
  automountMapName: auto.man
  
  dn: automountkey=/usr/man,automountmapname=auto.master,cn=automount,dc=example,dc=com
  objectClass: automount
  automountKey: /usr/man
  automountInformation: auto.man
  dn: automountkey=man1,automountmapname=auto.man,cn=automount,dc=example,dc=com
  objectClass: automount
  automountKey: man1
  automountInformation: nfsserver.example.com:/export/manpages/man1

Certificate Related Attributes and Objects

As part of the IPA v2 project we are going to integrate the certificate authority into IPA server. CA will share the back end DS with IPA as a data storage.

Certificate Storage

In IPA v2 there is no plan to provide the certificate authentication capabilities for users or allow services and hosts to authenticate to IPA using the certificate as an alternative to Kerberos keytab. However it will be beneficial from the very beginning to have proper object classes applied to user, host and service entries so that certificates can actually be published into those entries.

To accomplish this we will use the attributes and object classes defined in the rfc4523.


userCertificate - The userCertificate attribute holds the X.509 certificates issued to the user by one or more certificate authorities, as discussed in clause 11.2.1 of [X.509].

 attributeType ( 2.5.4.36 NAME 'userCertificate'
             DESC 'X.509 user certificate'
             EQUALITY certificateExactMatch
             SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )

As required by this attribute type's syntax, values of this attribute are requested and transferred using the attribute description "userCertificate;binary". This is the only attribute that needs to be added to those entries. It will be added using the following object class. This object class is used in augment entries for objects that may be subject to certificates, as defined in clause 11.1.1 of [X.509].

 objectClass ( 2.5.6.21 NAME 'pkiUser'
             DESC 'X.509 PKI User'
             SUP top AUXILIARY
             MAY userCertificate )

The pkiUser object class will be applied to user, service and host entries, so that the certificate can be published to those entries. For the user entry currently we already apply inetOrgPerson object class that contains the userCertificate attribute. However we think it would be beneficial to also apply pkiUser class to user entry so that we can easily search for all the entries that can have userCertificate attribute in the system.

CA Configuration

The attributes described below specify the data that will be associate with the CA as a whole. The pkiCA object will be created in the configuration section of the DIT in cn=CAConfig,cn=etc... The AUXILIARY class defined bellow will be applied to the dummy entry of the "top" class to create an single entry that would hold certificate authority related information.

Currently in IPA v1 there is no such entry.

cACertificate - The cACertificate attribute holds the X.509 certificates issued to the certificate authority (CA), as discussed in clause 11.2.2 of [X.509].

 attributeType ( 2.5.4.37 NAME 'cACertificate'
             DESC 'X.509 CA certificate'
             EQUALITY certificateExactMatch
             SYNTAX 1.3.6.1.4.1.1466.115.121.1.8 )

As required by this attribute type's syntax, values of this attribute are requested and transferred using the attribute description "cACertificate;binary".

crossCertificatePair - The crossCertificatePair attribute holds an X.509 certificate pair, as discussed in clause 11.2.3 of [X.509].

 attributeType ( 2.5.4.40 NAME 'crossCertificatePair'
             DESC 'X.509 cross certificate pair'
             EQUALITY certificatePairExactMatch
             SYNTAX 1.3.6.1.4.1.1466.115.121.1.10 )

As required by this attribute type's syntax, values of this attribute are requested and transferred using the attribute description "crossCertificatePair;binary".

certificateRevocationList - The certificateRevocationList attribute holds certificate lists, as discussed in 11.2.4 of [X.509].

 attributeType ( 2.5.4.39 NAME 'certificateRevocationList'
             DESC 'X.509 certificate revocation list'
             EQUALITY certificateListExactMatch
             SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )

As required by this attribute type's syntax, values of this attribute are requested and transferred using the attribute description "certificateRevocationList;binary".

authorityRevocationList - The authorityRevocationList attribute holds certificate lists, as discussed in 11.2.5 of [X.509].

 attributeType ( 2.5.4.38 NAME 'authorityRevocationList'
             DESC 'X.509 authority revocation list'
             EQUALITY certificateListExactMatch
             SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )

As required by this attribute type's syntax, values of this attribute are requested and transferred using the attribute description "authorityRevocationList;binary".

pkiCA object class is used to augment entries for objects that act as certificate authorities, as defined in clause 11.1.2 of [X.509]

 objectClass ( 2.5.6.22 NAME 'pkiCA'
             DESC 'X.509 PKI Certificate Authority'
             SUP top AUXILIARY
             MAY ( cACertificate $ certificateRevocationList $
                   authorityRevocationList $ crossCertificatePair ) )


Also in the same location in the DIT we might decide to store the revocation lists. cRLDistributionPoint class is used to represent objects that act as CRL distribution points, as discussed in clause 11.1.3 of [X.509].

 objectClass ( 2.5.6.19 NAME 'cRLDistributionPoint'
             DESC 'X.509 CRL distribution point'
             SUP top STRUCTURAL
             MUST cn
             MAY ( certificateRevocationList $ authorityRevocationList $ deltaRevocationList ) )
     

It may be simpler to add cRLDistributionPoint entry to IPA directory to have a place to store CRLs instead of defining it as part of the main CA entry (containing pkiCA). This aspect is yet to be decided.
The deltaRevocationList attribute used in this class holds certificate lists, as discussed in 11.2.6 of [X.509].

 attributeType ( 2.5.4.53 NAME 'deltaRevocationList'
             DESC 'X.509 delta revocation list'
             EQUALITY certificateListExactMatch
             SYNTAX 1.3.6.1.4.1.1466.115.121.1.9 )

As required by this attribute type's syntax, values of this attribute MUST be requested and transferred using the attribute description "deltaRevocationList;binary".

CA Access Control Configuration

The configuration entry most likely will be created under "cn=CAConfig, cn=etc,...". The configuration entry will contain two attributes. One is a standard "manager", "member" or "owner" attribute. This attribute has a DN syntax. It will point to DN of the group of users that are allowed to issue certificate commands. By default it will point to DN of the "admins" group that is created by default at the installation. If not present reference to "admins" group should be assumed. If we choose "manager" and want the referential integrity plugin to be able to track changes we would have to add "manager" attribute to the list of the attributes tracked by the referential integrity plugin. The "member" and "owner" attributes are already listed in the referential integrity attribute.

The other attribute defines client access policy. Though the clients would have the capability to request new certificates or track and renew old ones it does not mean that the server would blindly respect and execute these requests. The management plugin that interfaces with RA would have to determine that the current XML-RPC request is executed under host principal and not by an administrative user. In the same configuration entry that will hold the name of the group of user that would have access to certificate operations, there will be an attribute that would hold the policy that will control how server would react to the client requests to issue or renew a certificate. In IPA v2 there will be 3 supported values.

  • Always - always respect host's requests
  • Never (default) - automatically ignore all requests coming from hosts
  • Renew - respect only renew requests. The RA uses one and the same call for issuance and renewal so it is hard to differentiate the two scenarios. To react differently in case of certificate renewal the plugin will check the host (or service entry) for a certificate. If the certificate already exists in the entry, then the request will be treated as a renewal. If there is no certificate in the entry then it would be treated as a new request.
attributeType ( 2.16.840.1.113730.3.8.3.TBD
   NAME 'hostCApolicy' 
   DESC 'Policy on how to treat host requests for cert operations.' 
   EQUALITY caseIgnoreMatch 
   ORDERING caseIgnoreMatch 
   SUBSTR caseIgnoreSubstringsMatch 
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
   SINGLE-VALUE
   X-ORIGIN 'IPA v2')

If not present "Never" should be assumed.

Object class will look like this:

 objectclass ( 2.16.840.1.113730.3.8.4.TBD
   NAME 'ipaCAaccess' 
   STRUCTURAL 
   MAY (member $ hostCApolicy) 
   X-ORIGIN 'IPA v2' )

DNS

The following schema will be used for DNS integration. This schema is based on the SDB Schema with slight modifications.

attributetype ( 1.3.6.1.4.1.2428.20.0.0
	NAME 'dNSTTL'
	DESC 'An integer denoting time to live'
	EQUALITY integerMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

attributetype ( 1.3.6.1.4.1.2428.20.0.1
	NAME 'dNSClass'
	DESC 'The class of a resource record'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.0.2
	NAME 'zoneName'
	DESC 'The name of a zone, i.e. the name of the highest node in the zone'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.0.3
	NAME 'relativeDomainName'
	DESC 'The starting labels of a domain name'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.12
	NAME 'pTRRecord'
	DESC 'domain name pointer, RFC 1035'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.13
	NAME 'hInfoRecord'
	DESC 'host information, RFC 1035'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.14
	NAME 'mInfoRecord'
	DESC 'mailbox or mail list information, RFC 1035'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.16
	NAME 'tXTRecord'
	DESC 'text string, RFC 1035'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.18
	NAME 'aFSDBRecord'
	DESC 'for AFS Data Base location, RFC 1183'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.24
	NAME 'SigRecord'
	DESC 'Signature, RFC 2535'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.25
	NAME 'KeyRecord'
	DESC 'Key, RFC 2535'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.28
	NAME 'aAAARecord'
	DESC 'IPv6 address, RFC 1886'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.29
	NAME 'LocRecord'
	DESC 'Location, RFC 1876'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.30
	NAME 'nXTRecord'
	DESC 'non-existant, RFC 2535'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.33
	NAME 'sRVRecord'
	DESC 'service location, RFC 2782'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.35
	NAME 'nAPTRRecord'
	DESC 'Naming Authority Pointer, RFC 2915'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.36
	NAME 'kXRecord'
	DESC 'Key Exchange Delegation, RFC 2230'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.37
	NAME 'certRecord'
	DESC 'certificate, RFC 2538'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.38
	NAME 'a6Record'
	DESC 'A6 Record Type, RFC 2874'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.39
	NAME 'dNameRecord'
	DESC 'Non-Terminal DNS Name Redirection, RFC 2672'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.43
	NAME 'dSRecord'
	DESC 'Delegation Signer, RFC 3658'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.44
	NAME 'sSHFPRecord'
	DESC 'SSH Key Fingerprint, draft-ietf-secsh-dns-05.txt'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.46
	NAME 'rRSIGRecord'
	DESC 'RRSIG, RFC 3755'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 1.3.6.1.4.1.2428.20.1.47
	NAME 'nSECRecord'
	DESC 'NSEC, RFC 3755'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 0.9.2342.19200300.100.1.26 
	NAME 'aRecord'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 0.9.2342.19200300.100.1.29 
	NAME 'nSRecord'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 0.9.2342.19200300.100.1.31
	NAME 'cNAMERecord'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 0.9.2342.19200300.100.1.28
	NAME 'mXRecord'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 0.9.2342.19200300.100.1.27
	NAME 'mDRecord'
	EQUALITY caseIgnoreIA5Match
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

attributetype ( 2.16.840.1.113730.3.8.3.TBD
	NAME 'idnsName'
	DESC 'DNS FQDN'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
	SINGLE-VALUE
	X-ORIGIN 'IPA v2' )

attributetype ( 2.16.840.1.113730.3.8.3.TBD
	NAME 'idnsAllowDynUpdate'
	DESC 'permit dynamic updates on this zone'
	EQUALITY booleanMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
	SINGLE-VALUE
	X-ORIGIN 'IPA v2' )

attributetype ( 2.16.840.1.113730.3.8.3.TBD
	NAME 'idnsZoneActive'
	DESC 'define if the zone is considered in use'
	EQUALITY booleanMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.7
	SINGLE-VALUE
	X-ORIGIN 'IPA v2' )

attributetype ( 2.16.840.1.113730.3.8.3.TBD
	NAME 'idnsSOAmName'
	DESC 'SOA Name'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
	SINGLE-VALUE
	X-ORIGIN 'IPA v2' )

attributetype ( 2.16.840.1.113730.3.8.3.TBD
	NAME 'idnsSOArName'
	DESC 'SOA root Name'
	EQUALITY caseIgnoreIA5Match
	SUBSTR caseIgnoreIA5SubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
	SINGLE-VALUE
	X-ORIGIN 'IPA v2' )

attributetype ( 2.16.840.1.113730.3.8.3.TBD
	NAME 'idnsSOAserial'
	DESC 'SOA serial number'
	EQUALITY numericStringMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36
	SINGLE-VALUE
	X-ORIGIN 'IPA v2' )

attributetype ( 2.16.840.1.113730.3.8.3.TBD
	NAME 'idnsSOArefresh'
	DESC 'SOA refresh value'
	EQUALITY numericStringMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36
	SINGLE-VALUE
	X-ORIGIN 'IPA v2' )

attributetype ( 2.16.840.1.113730.3.8.3.TBD
	NAME 'idnsSOAretry'
	DESC 'SOA retry value'
	EQUALITY numericStringMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36
	SINGLE-VALUE
	X-ORIGIN 'IPA v2' )

attributetype ( 2.16.840.1.113730.3.8.3.TBD
	NAME 'idnsSOAexpire'
	DESC 'SOA expire value'
	EQUALITY numericStringMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36
	SINGLE-VALUE
	X-ORIGIN 'IPA v2' )

attributetype ( 2.16.840.1.113730.3.8.3.TBD
	NAME 'idnsSOAminimum'
	DESC 'SOA minimum value'
	EQUALITY numericStringMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.36
	SINGLE-VALUE
	X-ORIGIN 'IPA v2' )

objectclass ( 2.16.840.1.113730.3.8.4.TBD
	NAME 'idnsRecord'
	DESC 'dns Record, usually a host'
	SUP top
	STRUCTURAL
	MUST idnsName
	MAY ( cn $ idnsAllowDynUpdate $ DNSTTL $ DNSClass $ ARecord $
		AAAARecord $ A6Record $ NSRecord $ CNAMERecord $ PTRRecord $
		SRVRecord $ TXTRecord $ MXRecord $ MDRecord $ HINFORecord $
		MINFORecord $ AFSDBRecord $ SIGRecord $ KEYRecord $ LOCRecord $
		NXTRecord $ NAPTRRecord $ KXRecord $ CERTRecord $ DNAMERecord $
		DSRecord $ SSHFPRecord $ RRSIGRecord $ NSECRecord ))

objectclass ( 2.16.840.1.113730.3.8.4.TBD
	NAME 'idnsZone'
	DESC 'Zone class'
	SUP idnsRecord
	STRUCTURAL
	MUST ( idnsName $ idnsZoneActive $ idnsSOAmName $ idnsSOArName $
		idnsSOAserial $ idnsSOArefresh $ idnsSOAretry $ idnsSOAexpire $
		idnsSOAminimum ))