banners
From Free IPA
Current pages summarizes earlier attempts to define objects in the DS that will represent different concepts.
Contents
|
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 exact mechanism for GUID generation is yet to be defined. We might decide to implement a DS plugin that will return GUIDs or implement GUID generation algorithm on the LDAP client side. The following RFC defines an industry standard for the UUID generation rfc4122.txt. The DS code base has the logic to generate GUIDs so it can be used as reference implementation.
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 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 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 ))
