1 / 23

Directory Integration

Directory Integration Our intended approach to user account management. Pete Mitchell, Dave Anderson – Netware Team, Computing Service. Directory Integration - Terminology Directories ?

Audrey
Download Presentation

Directory Integration

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Directory Integration Our intended approach to user account management. Pete Mitchell, Dave Anderson – Netware Team, Computing Service.

  2. Directory Integration - Terminology • Directories ? • The Directory is the part of any service which retains the authentication data, commonly a username and a password, most of the time it’s not separate from the rest of the OS. • In NT it’s the Domain Database (SAM), in UNIX it’s commonly the NIS database, in Netware it’s the eDirectory. • Member systems • Used to refer to the systems which provide the services to our users, i.e. the NDS or the UNIX system, or the exchange system.

  3. Why Integrate ? • Many of us now have multiple accounts, for many systems to access the services we need. • In most cases these accounts are not necessarily the same, in lots of cases they are very different, often a combination of central and local accounts. • There does not exist a mechanism to keep these accounts in sync, across all the systems we need to use.

  4. Too much to remember • Problem - too many tokens! • with multiple accounts, across multiple systems with potentially multiple different administrators coordinating changes is almost impossible. • Under these circumstances users tend to either leave the password at the value it was when they received it, or change it to the same value of their other passwords, meaning they either have to remember multiple passwords or they end up with one they can’t change because changing it in one place means changing it everywhere. • A Password policy is impossible to implement in the above scenario (or rather, impossible to enforce). • It’s a pain for our users (and for us)!

  5. Multiple access example • Standard Staff Desktop • CARU SSD user currently needs a minimum of three accounts for access to their desktop. • NDS account for workstation management. • NT Domain account for Exchange access. • MIS NIS account for SAMBA access to filestore • Potentially the user may also get username/passwords for dial in, vpn, studentbase, department database etc.

  6. Audit • Problem – auditing access to data • The existing arrangement means there is a high number of redundant accounts, meaning it’s very difficult to ensure all access is removed in a timely fashion. • Users retain rights to data long after they should. • Different representations for users means we can disable one account, but they retain access via a second account.

  7. All of campus ? • Problem - Campus wide initiatives • It’s very difficult to address the whole user base as there is no definitive source for authentication data. • Forthcoming inter-institution initiatives require common authentication for users ( e.g. Shibboleth ) to access remote services. • Need to move to the same representation as we currently have for students.

  8. Service Evolution • Problem – how our services evolve. • The evolution of services can become tied to the platform which hosts the users identities, rather than the best platform for the job. • Need to break the reliance on where users are initially created for the expansion of service. • Facilitate an environment where we choose best technology for a service.

  9. Aaaarrrgghhh! • The current arrangement confuses our users, confounds our administrators, restricts our ability to offer connected services to the whole of our user base, reduces our options going forward and costs us more money, while driving a coach and horses through any password and audit policy we implement ! • It needs to change.

  10. The Challenge • We need to move to a system that offers a more consistent representation of staff and students across multiple systems, that will allow :- • Timely creation/modification and deletion of accounts. • Audit trail against central records. • A single authority for services covering the whole University. • (optional) Password synchronisation. • The implementation of a rigorous password policy.

  11. Directory Integration – Who • In the first instance we will be able to address new accounts and existing accounts in systems that follow the unique identifier scheme already employed. • If a users’ account is to be part of the automation process all of the accounts that represent that user will need to be changed to the unique form in the systems that wish to participate. We don’t know yet if we can opt some in and some out, which would be ideal. • It goes without saying that the alignment exercise will be painful.

  12. Not single sign on - account match up • If your username/password combo are the same across multiple systems is doesn’t matter where the access is granted to the user, they just supply the same information. • Departments may integrate their own systems with central provision transparently (should they choose to do so).

  13. What to we need to start • A one to one representation between user and entry in the HR/Registry database. • An agreed standard for unique identifiers for each user account. • An agreed password policy. • An agreed definition of department/faculty codes and where user accounts should reside.

  14. Directory Integration – How • We need to extrapolate the representation of the user from the member systems, then store this in a Directory called the Meta Directory (or in nSure parlance, the Identity Vault ). This then becomes the default “lookup” for authentication information. • Connect the Identity Vault ( Meta Directory ) to the real systems, and implement two way synchronisation between the Meta Directory and the real systems ( member systems ).

  15. Meta Directory/Identity Vault • Meta Directory (Identity Vault) • Starting at the definitive source for the data (HR and Registry) extract the data required for each user such as name, address and some of the data about their relationships to other users/departments. • Allow the user to augment this data with a number of tailored challenges to allow future changes to the data, i.e. challenge/response sets. • Provide the relevant inbound routes for lookup from external systems.

  16. Event driven • Once populated the systems monitors the databases in HR and registry for changes, each change triggering the relevant event. • The system allows for some logic to be applied before and after each event. • System can also detect events in the member systems (i.e. password change) and feed the data back into the Meta Directory.

  17. Example - Account creation • Proposed new system – new staff member • Addition to HR database triggers a creation event in the Meta Directory. • Named account is created in the Meta Directory. • This triggers a creation in the NDS, the NT Domain and the NIS database, with the same name and password.

  18. Example - Account disabling • Proposed new system – end of employment • Modification of status in HR database triggers account archival event. • Member systems disable accounts, migrate to expired areas etc. • Account removed from relevant mailing lists, group accounts.

  19. Password Sync • Password Sync • Most systems support password sync which allows a password change in one system to be promulgated back to the Meta Directory and from there to the other systems on which the user is registered. • Our intention to enable this for NDS, ADS and NIS passwords in the first pass.

  20. Password Sync ( cont ) • Password Sync • Password sync installs native software on member system to intercept password change events at OS native layer, then promulgate these changes back to the meta directory. From here they are sent to the other systems. • Some member systems not supported, and others whose password flexibility means using the same password is not possible.

  21. Technology • Technology • Novell’s NSure. An XML based system with loads of out the box connectors. • Meta Directory – Novell’s eDirectory 8.7.x running on 2 x NW OES Servers and 1 x Windows 2003 server. • Extendable, secure, high performance with native access from a Netware, Windows and UNIX/LINUX.

  22. Currently supported systems • What can we support now • NSure Identity Manager Driver for Active Directory • NSure Identity Manager Driver for Delimited Text • NSure Identity Manager Driver for Exchange • NSure Identity Manager Driver for GroupWise • NSure Identity Manager Driver for Novell® eDirectory™ • NSure Identity Manager Driver for NT Domain • NSure Identity Manager Driver for Lotus Notes • NSure Identity Manager Driver for LDAP- Supports: iPlanet Directory Server, IBM SecureWay Directory, Innosoft Directory, Critical Path Directory Server • NSure Identity Manager Driver for JDBC- Supports: Oracle, Microsoft SQL Server, IBM DB2 Universal Database

  23. Demonstration • A brief demo of the NSure system, with an example based on the imminent Janitor replacement for the student system ( Janitor is our in house tool for student account creation and management ).

More Related