EDIRrole and Associated iPlanet Roles

Original author: Beth Mercer - 20081103

Note: Though out this document are references to ldap_*<Inst> commands. Those are simply scripted invocations of the associated ldap* utilities that make it possible to search the directory, and to add, modify and delete directory data using the Directory Manager credentials. The ldap_*<Inst> scripts can be found on the "e" boxes under ~iplanet/local/ldap/scripts.

EDIRrole Overview

EDIRrole is a locally defined attribute used to make attribute based authorization decisions within EDIR, AUTHSERV, their UPDATE back end and at the directory level itself. Within the web gateways, the presence or absense of an EDIRrole value determines whether or not a user is allowed to interact with an administrative form. At the UPDATE back end, the presence or absense of an EDIRrole value determines whether or not a restricted function relying on agent credentials rather than user credentials will be performed at the request of a particular user. At the directory level, EDIRrole values are referenced by iPlanet roles which are associated with ACIs that provide update access to groups of directory records.

EDIRroles are given meaning by the web gateways, backend and directory roles that reference them.

EDIRrole General Groupings

There are currently 2900+ distinct EDIRrole values but most fall under the following general categories:

EDIRrole Identity	Permissions Granted
ADadmin	Administration of AD related attributes
EDIRadmin	Administration of any self service attribute
abideByFERPA	View FERPA protected student records
deptAdmin<unitUIDpattern>	Update unit records
emailAdmin	Administration of email related attributes
emplAdmin<unitUIDpattern>	Update people records associated with unit
helpDesk	Perform restricted account management tasks
phoneBook	Administration of phoneBook related attributes
secretaryAdmin	Administration of the secretary attribute
sponsorAccount	Sponsor directory records (includes guest account creation )
tklAdmin<TKLpattern>	Update people records associated with TKL

The greatest variety exists in the deptAdmin* emplAdmin* and tklAdmin* EDIRrole values. Those roles are scoped to allow access to a single unit/TKL or a group of units/TKLs which roll up to a common record.

EDIRrole Provisioning

EDIRrole values are provisioned on ou=people records by the ZUAUSR application when it processes super classes that contain EDIR related grants. Since ZUAUSR is an application that supports provisioning of administrative access only to employee accounts (and a handful of exceptions), EDIRrole values must be manually provisioned by OIT Technical Services Account Administration staff on ou=resource records and on any ou=people records not handled by ZUAUSR.

iPlanet Roles

The iPlanet roles based on EDIRrole values are divided into two categories:

• those that apply to people accessing other records
• those that apply to resource accounts accessing other records.

The iPlanet roles that govern people's access require that the person requesting access have a current job assignment. That helps insure that users who leave the university do not retain viable directory access even if account administration practices do not result in the timely revocation of administrative accesses. The following example shows the controls for permission to administer EDIR.

$ iplanet@egegik> cat role.EDIRadminRole.ldif         
dn: cn=EDIRadminRole,ou=people,dc=alaska,dc=edu
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: EDIRadminRole
nsRoleFilter: (&(EDIRROLE=*)(EDIRrole=EDIRadmin)(eduPersonAffiliation=Employee)(assignmentCount=*)(!(assignmentCount=0)))
Description: filtered role for entities administering EDIR

Resource credentials on the other hand are granted to applications not people and applications do not have current job assignments so the assignment criteria is omitted:

$ iplanet@egegik> cat role.EDIRadminRole.resource.ldif
dn: cn=EDIRadminRole,ou=resource,dc=alaska,dc=edu
objectclass: top
objectclass: LDAPsubentry
objectclass: nsRoleDefinition
objectclass: nsComplexRoleDefinition
objectclass: nsFilteredRoleDefinition
cn: EDIRadminRole
nsRoleFilter: (&(EDIRROLE=*)(EDIRrole=EDIRadmin))Description: filtered role for resource entities administering EDIR

Managing iPlanet Roles

The legacy method for managing iPlanet roles was to access a role.<role name>.ldif file and modify the LDAP EDIR listing accordingly. I find no evidence of the following on the production iPlanet directories for the IDMP cluster. If these are used, they are used solely via EDIR, despite the LDAP scripts and management details residing on idml-3.alaska.edu.

Current IAM documentation refers users to the Sun iPlanet documents to complete these tasks.

Legacy iPlanet Roles

The following is a listing of LDIF files remaining on the "E" boxes that correspond to iPlanet roles that were defined in the legacy method:

iplanet@edgar.alaska.edu> find . -name role.*
./local/ldap/schema/ROLE/role.HelpDeskRole.ldif.20050511elm
./local/ldap/schema/ROLE/role.EDIRadminRole.resource.ldif
./local/ldap/schema/ROLE/role.emailAdminRole.ldif.20050511elm
./local/ldap/schema/ROLE/role.passwordSynchRole.resource.ldif
./local/ldap/schema/ROLE/role.authserviceRole.resource.ldif
./local/ldap/schema/ROLE/role.twoStepBindrole.resource.ldif
./local/ldap/schema/ROLE/role.EDIRadminRole.ldif
./local/ldap/schema/ROLE/role.authservicePrivilegedRole.resource.ldif
./local/ldap/schema/ROLE/role.acceptedFERPArole.ldif.20060407elm
./local/ldap/schema/ROLE/role.HelpDeskRole.ldif
./local/ldap/schema/ROLE/role.EDIRadminRole.departments.ldif
./local/ldap/schema/ROLE/role.deptAdminRole.ldif.20050511elm
./local/ldap/schema/ROLE/role.ADadminRole.ldif
./local/ldap/schema/ROLE/role.abideByFERPArole.resource.ldif
./local/ldap/schema/ROLE/role.ADadminRole.people.ldif
./local/ldap/schema/ROLE/role.HelpDeskStudentRole.ldif.20050422elm.not_used
./local/ldap/schema/ROLE/role.deptAdminRole.ldif.20030908eml
./local/ldap/schema/ROLE/role.directoryGatewayRole.ldif
./local/ldap/schema/ROLE/role.phoneBookRole.ldif.20050511elm
./local/ldap/schema/ROLE/role.superUserRole.resource.ldif
./local/ldap/schema/ROLE/role.secretaryAdminRole.ldif.20050511elm
./local/ldap/schema/ROLE/role.EDIRadminRole.routing.ldif
./local/ldap/schema/ROLE/role.directoryPrivilegedRole.resource.ldif
./local/ldap/schema/ROLE/role.authserviceRole.ldif
./local/ldap/schema/ROLE/role.phoneBookRole.ldif.20050303
./local/ldap/schema/ROLE/role.emailAdminRole.resource.ldif.20050603elm
./local/ldap/schema/ROLE/role.directoryGatewayRole.resource.ldif
./local/ldap/schema/ROLE/role.EDIRadminRole.resource.ldif.20070607
./local/ldap/schema/ROLE/role.passwordSynchRole.ldif
./local/ldap/schema/ROLE/role.EDIRadminRole.resource.ldif.20060710
./local/ldap/schema/ROLE/role.administratorsRole.ldif
./local/ldap/schema/ROLE/role.acceptedFERPArole.ldif
./local/ldap/schema/ROLE/role.passwordSynchRole.ldif.20060511
./local/ldap/schema/ROLE/role.passwordSynchRole.ldif.20070307
./local/ldap/schema/ROLE/role.GAE-EDIRgadgetRole.resource.ldif
./local/ldap/schema/ROLE/role.directoryPrivilegedRole.ldif
./local/ldap/schema/ROLE/role.acceptedFERPArole.ldif.20050511elm
./local/ldap/schema/ROLE/role.EDIRadminRole.group.ldif
./local/ldap/schema/ROLE/role.HelpDeskRole.resource.ldif.20050603elm
./local/ldap/schema/ROLE/role.ADadminRole.resource.ldif
./local/ldap/schema/ROLE/role.authservicePrivilegedRole.ldif
./local/ldap/schema/ROLE/role.emplAdminRole.ldif.20050203
./local/ldap/schema/ROLE/role.tklAdminRole.ldif
./local/ldap/schema/ROLE/role.abideByFERPArole.resource.ldif.20070607
./local/ldap/schema/ROLE/role.emailAdminRole.ldif
./local/ldap/schema/ROLE/role.phoneBookRole.ldif
./local/ldap/schema/ROLE/role.emplAdminRole.resource.ldif
./local/ldap/schema/ROLE/role.UaSystemIdRole.resource.ldif
./local/ldap/schema/ROLE/role.secretaryAdminRole.ldif
./local/ldap/schema/ROLE/role.emplAdminRole.ldif.20050511elm
./local/ldap/schema/ROLE/role.EDIRadminRole.ldif.20050511elm
./local/ldap/schema/ROLE/role.deptAdminRole.ldif
./local/ldap/schema/ROLE/role.emplAdminRole.ldif
./local/ldap/schema/ROLE/role.CurrentMailRole.resource.ldif
./local/ldap/schema/ROLE/role.tklAdminRole.ldif.20050511elm
./local/ldap/schema/ROLE/role.administratorsRole.ldif.20050511elm
./local/ldap/schema/ROLE/role.authserviceRole.ldif.tmp
./local/ldap/schema/ROLE/role.abideByFERPArole.ldif
./local/ldap/schema/ROLE/role.HelpDeskRole.ldif.20030716elm

Running the Scripts to Add and Delete Defined Roles

To delete a role enter ldap_delete<instance> at the command line prompt. The output will resemble the following:

	iplanet@egegik> ldap_deleteTest 
	inst: test
	port: 13338
	
	
	ldapdelete: started Mon Nov  3 16:35:08 2008
	
	ldap_init( egegik, 13338 )
	ldaptool_getcertpath -- /e01/iplanet/servers/alias/slapd-egegiktest-cert8.db
	ldaptool_getkeypath -- /e01/iplanet/servers/alias/slapd-egegiktest-cert8.db
	ldaptool_getdonglefilename -- (null)
	cn=EDIRadminRole,ou=resource,dc=alaska,dc=edu
	deleting entry cn=EDIRadminRole,ou=resource,dc=alaska,dc=edu
	entry removed
	<ctrl+d>

To add a role, enter ldap_add<instance> at the command line prompt. The output will resemble the following:

	iplanet@egegik> ldap_addTest -f role.EDIRadminRole.resource.ldif             
	inst: test
	port: 13338
	
	
	ldapmodify: started Mon Nov  3 16:35:25 2008
	
	ldap_init( egegik, 13338 )
	ldaptool_getcertpath -- /e01/iplanet/servers/alias/slapd-egegiktest-cert8.db
	ldaptool_getkeypath -- /e01/iplanet/servers/alias/slapd-egegiktest-cert8.db
	ldaptool_getdonglefilename -- (null)
	add objectclass:
	        top
	        LDAPsubentry
	        nsRoleDefinition
	        nsComplexRoleDefinition
	        nsFilteredRoleDefinition
	add cn:
	        EDIRadminRole
	add nsRoleFilter:
	        (&(EDIRROLE=*)(EDIRrole=EDIRadmin))
	add Description:
	        filtered role for resource entities administering EDIR
	adding new entry cn=EDIRadminRole,ou=resource,dc=alaska,dc=edu
	modify complete

iPlanet roles created for ou=people,dc=alaska,dc=edu and ou=resource,dc=alaska,dc=edu in a directory instance on one server are automatically replicated to the same directory instance on all other servers. That is because roles are simply another form of directory data and those branches of the directory are configured for automatic replication of directory data changes.