1. Two Issues in Directory Operations Dr. Tom Barton The University of Memphis & Internet2

2. 1 August 2002Advanced CAMP2 You will recognize this part of the talk as a middleware talk, using Brendan’s criteria: Rambling Incoherent And, lieu of the requirement for humor I’ll substitute monotone, mumbling vocals.

3. 1 August 2002Advanced CAMP3 And those 2 issues are… 1.Monitoring replication with iPlanet DS v4.X 2.A stateful automated provisioning model. Offered as dissections from which to learn,not as recommendations for best practice.

4. 1 August 2002Advanced CAMP4 Replica roles at UoM 1.Mailbox server only. High volume, just the indices necessary for this function. 2.General purpose email routing, white pages, RADIUS backend, everyday ldap client applications. Moderately indexed. 3.Low volume but high indexing demand for certain applications. 4.Master should ideally be write-only.

5. 1 August 2002Advanced CAMP5 Replicas – raison d’etre Replica specific indexing and/or administrative limits to support dependent applications Fault isolation & tolerance Performance of ldap provided authN|Z services

6. 1 August 2002Advanced CAMP6 Replication channel delay concerns At UoM, all updates to ldap directory are asynchronous – we never rebuild the DIT. Daily updates from CBSs can range up to 100K changes Many applications use replicas for authN|Z. Near real time propagation of changes is needed. Some applications use enterprise ldap directory as repository – benefit from integration with enterprise data. Netreg

7. 1 August 2002Advanced CAMP7 Solutions & challenges All (well, almost all) changes are “dribbled” in to maintain headroom in replication channel. Sleep for a set number of milliseconds after writing each transaction, by transaction type. Big brother monitors replication backlog (details later). Some apps go bad and dump tons of changes undribbled (e.g., webmail personal prefs, at times).

8. 1 August 2002Advanced CAMP8 Available replication data Replication activity logging can be enabled (to errors log) – very granular. Basic replication data stored in DIT by DSAs Master (in root DSE): lastChangeNumber, netscapeReplicaState Consumers (in object readable only by Directory Manager): replicaUpdateReplayed

9. 1 August 2002Advanced CAMP9 bb replication monitor Simple model of replication channel headroom based on baseline TPM and data update intervals. Experientially determined alarm levels. BB checks each 5 minutes, and consumers only update data in DIT about that often.BB

10. 1 August 2002Advanced CAMP10 Observations Valuable – issues with service noticed and corrected quickly. Specific to iPlanet DS v4.X. Even iPlanet DS v5.X doesn’t do replication the same way. In fact, DS v5.X does not maintain data with which replication delay can be witnessed… LDUP’s Update Vector appears to provide sufficient data to characterize replication channel performance.

11. 1 August 2002Advanced CAMP11 Automated stateful provisioning Basic account provisioning is guided by a finite state machine. Managed resources include shell accounts IMAP/POP/HTTP mailbox service campus-wide computing cluster access variety of directory enabled application and web services that use an LDAP directory for access control, or that use the LDAP directory to determine eligibility for service.

12. 1 August 2002Advanced CAMP12 States embody levels of service Provisioning profiles Full access to basic services –Faculty, staff, enrolled student Email & identity management, including PIN maintenance for access to administrative web applications –Accepted student, registered student Identifiers maintained for continued support for outsourced services –alum Steps between these and oblivion Notification of impending doom Access denied Resources deleted

13. 1 August 2002Advanced CAMP13 Independent variables for state transitions state substate date the present state was reached date by which the present state might end (expiration date) major affiliation (faculty, staff, enrolled student, accepted student, registered student, alum) multivalued attribute holding the identifiers of resources being managed for this account.

14. 1 August 2002Advanced CAMP14 UoM next generation state model

15. 1 August 2002Advanced CAMP15 Operational benefits “the basic value proposition schtick” (cf. “Middleware Business Case”)Middleware Business Case Smooth over issues with feeds from source systems (grace state) Provide continuity of service to persons who temporarily drop out of source systems Absence from a CBS need not imply absence from Univ community. Avoid deletion of resources for persons not in fact departed (limbo state).

16. 1 August 2002Advanced CAMP16 Issues Expression of former affiliation Exposed during graceful removal? “accidental” nature of residual affiliation Guest account management manageGuest – thumbs up Sponsored account management Managed by humans – well, supposed to be..

17. 1 August 2002Advanced CAMP17 Mware value prop Reduces the number of credentials constituents must know to perform actions for which they are authorized. Reduces the implicit denial of service experienced by new members of an organization. Efficiently enable constituents to perform actions for which they are authorized. In particular, reduces the incremental cost to implement a new online service. Reduces the operational and management overhead of disabling authorization for clients who should no longer have access to online resources.

18. 1 August 2002Advanced CAMP18 Mware value prop Enables quick modification of access permissions as the client’s role, and so their set of authorizations, changes. Improves the quality of auditing of authorized actions across the organization by using identifiers common to all applications. Increase confidence that the credential presented by someone is presented by the person to whom the credential was intended, by reducing the number of people and offices involved in issuing credentials and improving the procedures followed by those few offices which do issue credentials.