IdM: Building Walls while Breaking Down Barriers

Kim McDonnell is an accounts analyst and Bry-Ann Yates is a program analyst, as part of the Identity and Access Management team, Information Technology Services, University of Albany, SUNY.

Implementing an institution-wide identity management (IdM) program does not have to be painful. At the University at Albany (UAlbany) SUNY, the Identity and Access Management team within Information Technology Services (ITS) learned how IdM can energize collaboration and relationships across the university. The central IT benefits of automation and security are only part of the story.

Many institutions have recently begun implementing IdM solutions, an undertaking that often depends on successfully identifying needs and securing adequate funding and manpower, and can seem overwhelming. UAlbany developed an IdM program that uses change management, communication, and outreach to help the entire university community embrace this new world.

"Identity management is a key piece in a secure, well-managed enterprise IT environment. The higher education environment is especially challenging when dealing with IdM due to the high turnover of students and the multiple roles that an individual can have. ITS at the University at Albany worked diligently to deal with the multiple issues over multiple departments and implemented a solution."
— Helen Strother, Director of Computing Services, College of Arts and Sciences, UAlbany

IdM solutions revolve around data from several sources, but the primary providers are human resources (HR) and the registrar's office. In developing our program, we spent considerable time working with our data providers. When developing our de-provisioning process — that is, the process of closing or removing access based on a person's status at the university — we worked extensively with HR personnel to better understand their processes and teach them about our own. Although we initially found each other's business practices confusing, the collaboration process helped us develop a mutual understanding that led to a more integrated workflow, facilitating greater efficiency on both sides. This new-found camaraderie became even more beneficial to the university community when HR and our IdM team worked together on outreach to university stakeholders.

The Problem

When UAlbany decided to migrate from its own in-house mail system to Microsoft's Live@edu, we had to create an Active Directory (AD) account for every person and shared resource that required a mailbox. Previously, all university members (34,000) automatically received a UNIX mail account; members received an AD account only if they were university administrators or had a special need. This amounted to approximately 5,000 total AD accounts to maintain. The mail system change required us to maintain an additional 29,000 AD accounts; this increase in number also increased the maintenance complexity.

The original 5,000 accounts were a known entity, consisting of professional staff with a low turnover rate. The new accounts, however, included everyone at the university, from students and adjuncts to professors and volunteers. Student employees were a particular concern. Prior to the mail migration, only those students who were employed at the university received an AD account; this gave them access to shared resources, which required special departmental approval. Each student employee account was created with an end date so that the account would automatically be disabled at the predetermined time, removing shared resource access. Once all students received an AD account for their entire time at UAlbany, we were no longer able to disable student employees' accounts at the end of their employment. Instead, resource managers had to recognize when a student should no longer have access to a resource, and promptly remove it. In our experience, access was often given, but resource managers seldom remembered to remove it.

Another concern was departmental transfers, as we had no way to identify when a user moved from one department to another. Our process consisted of sending AD group audit reports to resource managers at each semester's end, requesting that the managers review access. This stop-gap measure still potentially gave unauthorized users access to resources for up to 15 weeks past their departure date. We clearly needed a better, timelier method to handle departmental transfers.

"When I first learned about the de-provisioning project, I was nervous that it would create a lot of extra work for me and be difficult to understand and to use. As it turns out, de-provisioning and the identity management interface have been real time-savers and quite easy to understand…. The comfort I have with interpreting the email notifications and in using the Group Access Manager is due largely to the training and support received from the team in ITS. We were invited to attend a training seminar which provided clear information, and we received (still receive) excellent post-training support."
— Alison Olin, Assistant Dean, Dean's Office, School of Education, UAlbany

Our most significant hurdle was the sheer volume of accounts. Our Identity and Access Management Group (IAMG) has a staff of four people and, although skilled at our jobs, manually managing approximately 5,000 AD accounts and their resources was time consuming and inefficient. As figure 1 shows, the manual termination process took anywhere from five to 25 minutes, depending on the complexity of an individual's role at the university. As with any manual process, errors occasionally occurred. When the number of AD accounts increased by 580 percent (see figure 2), we knew automation was crucial.

Solutions Considered

An automated de-provisioning solution had to address several issues. The two primary issues were the project's scope and the resources — both people and systems — available to us. We also had to consider where the information resided, the effects the new process would have on existing systems, and how to present it to our customers.

PeopleSoft

Implementing the logic in our system of record, PeopleSoft, would have several advantages. Much of the information that the de-provisioning program required resided within PeopleSoft; data processing timeliness would increase if the application and data ran on the same system. Also, the Application Development staff members who administer PeopleSoft have a strong understanding of it and the HR data it contains.

Another benefit to this solution would be that the programmer who assisted in developing the Albany EduPerson codes — which, as we describe below, are the foundation of all our IdM automated processes — would also be the main programmer for programming PeopleSoft. This would be significantly advantageous, because she already had a strong foundation in understanding both the HR data and student records.

This solution had drawbacks, however, including that PeopleSoft's additional processing demands might slow down other university processes, and limited resources would further tax our system and the PeopleSoft support staff. Also, PeopleSoft did not contain all of the information we wanted to provide to our customers.

Forefront Identity Manager (FIM)

Because Forefront Identity Manager (FIM) is our IdM solution, it would be ideal to have it process most of our business rules. However, FIM has a steep learning curve, and using it might have delayed our de-provisioning implementation and our ability to manage the account life cycle.

Solutions Chosen

In 2008, the team developed Albany EduPerson codes to facilitate automation of the student account-closure process. These codes have expanded as we continue to refine our UAlbany populations and categorize customers with greater granularity. After observing how well these codes worked for the student account-closure process, we developed codes to represent our professional population. For de-provisioning purposes, we used these codes to determine an employee's current status — that is, current employee, volunteer, or emeritus — and any changes to that status. For students, the codes identify if they are active at the university and if they are student employees.

The codes are determined within PeopleSoft and transferred to our primary Lightweight Directory Access Protocol (LDAP) system, 389, along with additional information such as name, department number, title, and whether the person currently has PeopleSoft access. Using this information lets us determine if a person has been terminated from the university. Once determined, an attribute is added to indicate the date the person will lose access to IT services. Because our employees typically leave in good standing (and often return and are re-provisioned) it was logical to allow them additional time. So, an automatic 30 days of additional access was decided on to accommodate paperwork delays and issues with grants. However, departmental contacts for de-provisioning can request immediate access removal if necessary through an urgent termination process.

When students complete their time at the university, they are marked with a "remove on" date, which is one year from their completion date. Thirty days before their accounts are to close, we notify users so that they can copy any needed files or data. We also established an exception process for those rare occasions in which short-term access is needed for an already expired account.

Once the LDAP processes have completed, the FIM processes commence. We organize users by primary role (faculty, employee, or student). Depending on an individual's role, we automatically grant them access to common area folders and personal file space. Using FIM and EduPerson codes lets us determine if a person has changed roles (such as from a student employee to just a student, or from an employee to emeriti); in such cases, we notify the department's de-provisioning contact(s). We send notifications for departmental transfers, role changes, and roles that have decreased at the university. Such notifications remind resource owners to use the Group Access Manager to review and remove any shared resource access deemed necessary. We also query resources such as UNIX and AD to determine and report our users' resource access.

As figure 3 shows, our team custom-engineered an automated de-provisioning notification process that notifies a department when a user's access level has decreased or a user has transferred to a different department.

To both receive de-provisioning notifications and act as an archive, we created mailboxes for every department (more than 200 mailboxes in all). As figure 3 shows, the departmental notification is in a Microsoft Excel spreadsheet and contains specific information such as account closure date, the user's name and UAlbany ID, and the transaction type (transfer, role change, or pending closure). The notification also lists any departmental resources owned and any access to Windows resources. This notification helps departmental representatives responsible for handling the rehiring, termination, and transfer of individuals, reminding them to make appropriate HR employment updates as necessary (such as when an individual whose account has closed has been rehired).

Access and Security Solutions

To remove access, the department representatives use the FIM Portal/Group Access Manager. The portal is a self-service product that lets managers and designated individuals update and review users' access to shared resources; AD controls most of our shared resources (departmental mailboxes and shared folders). The portal was rolled out to departments a few months prior to the de-provisioning project's launch. The portal contains more than 2,300 groups, 600 managers, and departmental contacts in addition to our regular users. This solution saved time for departments, which no longer have to submit manual requests for adding or removing access. After all, departments know best who should actually have access to their resources.

We also incorporated automated notification to service owners who handle RedDot and Linux access as part of de-provisioning. RedDot access is reported only on the day an individual's account is officially shut off. Linux access is reported within the 30-day window of an individual's scheduled termination. This gives the service owner the opportunity to make appropriate updates or take alternative measures as needed.

We created service-owner folders on our network for those third-party applications that do not authenticate to LDAP. We identified service owners and gave them access to folders on our network containing reports listing people who have been terminated or transferred at the university. Service owners can then remove access to their particular service as appropriate.

Finally, the Integrated Administrative System (IAS) training and support group had its own manual process in place for managing people with IAS PeopleSoft access at the university. The group manually handled notifications to eight other service providers when employees terminated or transferred departments. This was a time-consuming weekly activity that the de-provisioning process eliminated. We were able to incorporate daily notifications of people with IAS PeopleSoft access into our de-provisioning report to departments, as well as in a daily report to the IAS training and support group; this report listed only individuals whose status had changed.

"IAMG worked on setting up a process where we could do parallel testing between our existing account termination/transfer process and the new de-provisioning process prior to go-live. As we came across unique scenarios that we hadn't foreseen, Chris Zoller and I met to discuss them and then modified processes to accommodate these scenarios in the future. Some of the scenarios were cyclical in nature and only happened at a particular point in the semester or academic year. Since we had a lengthy project development timeframe, it enabled the entire de-provisioning project team to identify and provide an appropriate notification and de-provisioning solution for these scenarios."
— Liz Medvetz and Julie-Anne Crisafulli, ITS University Applications Development, UAlbany

Communication and Collaboration

With such a substantial change in the procedures and processes affecting our customers, communication was crucial. Our communication plan to the university community encompassed various methods; we approached it in collaboration with the HR, College of Arts and Sciences Computing department, and the University Applications Development Groups IAS training and support staff. We incorporated multiple e-mail notifications and conducted phone conversations with our customers. We also held in-person information sessions on all three of our campuses, both for our customers' convenience and to facilitate face-to-face meetings. Information sessions were tailored to the audience's specific needs and unique circumstances. University staff were encouraged to sign up for a session at their convenience. We, in turn, sent reminder notifications about upcoming information sessions and added them to staff members' personal calendars to encourage attendance and participation.

"IAMG sent out detailed emails to the service owners announcing the info session dates, times, and locations and did a great job documenting de-provisioning FAQs that were put out on the askIT wiki for the campus community to access if they didn't attend an info session. It was also a great way to provide follow-up information for questions/concerns raised at the info sessions."
— Liz Medvetz and Julie-Anne Crisafulli

The information sessions permitted a detailed overview of the de-provisioning project and the Group Access Manager, while also emphasizing the importance of IdM policy. The sessions were well attended and gave us an opportunity to meet customers and answer questions that are often difficult or lengthy to address through e-mail. Conducting information sessions also raised our awareness of customer concerns, thus allowing us to contemplate various ways to handle them.

This project let our team educate university staff on IdM, emphasize the adherence and enforcement of the IdM policy, and educate our customers as to how technology has progressed within our department. Prior to this project, we were known as the "Accounts & Access Group," which implied that our only job was to create accounts and reset passwords. Today, we are known as the Identity and Access Management Group, which is responsible for the entire account lifecycle, from creating to removing access to eventually deleting accounts (see figure 4).

The project helped to strengthen and foster our collaborative relationships across the university, breaking down barriers that often exist between departments and individuals. Through these collaborative efforts, we developed a better understanding of HR processes, how other departments operate and why, and how IT operates in other areas.

"I think the de-provisioning project just highlighted for campus departments yet another reason why it is so important that the status of their employees is up-to-date with Human Resources. It was a great collaborative effort. I can speak for HR that we learned much more about IT and how our work impacts other areas."
— Denise Szelest, Director of Human Resources, UAlbany

Previously, HR often received questions about the emeriti account life cycle. Our collaborative efforts with HR resulted in improved internal process changes that addressed emeriti retirement information. Our system provides accountability for emeriti access to university resources. We initially terminated those emeriti accounts that were no longer wanted or needed, and then developed an annual renewal notification procedure for emeriti who wanted to keep their accounts active. HR subsequently began incorporating this emeriti account life cycle information into their retirement information packages.

How It's Working

Our customers are enjoying the self-service aspect of the Group Access Manager, which has been a time saver for both the IAMG and our customers. Customers no longer have to manually look up account data or fill out request forms; instead, they can simply log in directly to the Group Access Manager and make the needed updates without IAMG assistance. Although group owners grant access to their groups, they can also view others within the group who currently have access. This can remind them when a user's access to a particular resource should be removed, ensuring that the right people have access to the right resources.

"The IdM group's communication about the process was excellent from the start, first to distributed IT and then to the individual network resource owners. The IdM project has made network resource owners aware of the need to maintain access rights and has given them the tools to do so easily."
— Helen Strother

Our customers find the de-provisioning notifications helpful for providing a list of departmental access upon transfer, role change, or termination from a department. The notifications also highlight scheduled terminations, which in many cases require revisions and updates to the HR system of record (such as when employees are rehired).

The emeriti process is also working well. Emeriti are now becoming accustomed to the process of replying to the notification if they wish to retain access. Should they miss the e-mail notification and find their account terminated, we can restore account access and reiterate the e-mail notification procedure, which gives them the flexibility to choose a more convenient renewal date (up to one year).

Lessons Learned

Our team learned several valuable lessons throughout the project process.

• First, we learned that there is no getting around bad data. Whether the data was simply entered late or was entered incorrectly, no amount of programming can fix it. Thus, it is always best to have "smart" data fields that alert users when required information has not been entered or is in the wrong format.
• Another lesson we learned was that Albany EduPerson codes can be very useful to groups beyond central IT who need to grant and restrict access; however, to avoid unforeseen complications in their implementation, users should meet with IAMG to learn the codes' meaning and use.
• Although we made our best attempt to program every possible scenario into our EduPerson codes and de-provisioning, unexpected fringe cases naturally arose. We thus instituted an exception code encompassing several variations.
• Our collaborative efforts showed us that you should not presume to understand why a department operates in a particular way. Departments have different rules depending on their needs. Collaborating throughout the project gave us a better understanding of why certain processes were accomplished in a particular manner.

"As one of the collaborating IT teams representing University Applications Development in the University at Albany's de-provisioning project, Julie-Anne Crisafulli and I were impressed by the number of meetings the staff from IAMG had with us to identify the IT Applications, service providers, and users impacted by the new process. They patiently answered all of our questions from the initial start of the project throughout the year-and-a-half of development/planning phase and then through the actual 'go-live' date and in the weeks after go-live…. Overall, the de-provisioning project went very well for us due to the organization and open lines of communications that the staff from IAMG maintained throughout the entire project timeline. They provided great attention to detail during the project's development phase so that the go-live date would go as smoothly as possible."
— Liz Medvetz

Future Plans

Now that FIM has been in production for more than two years and our group has confidence in it, we have decided to investigate the requirements to move our application's de-provisioning logic into FIM.

We also intend to develop a reporting system that identifies those authorized to use third-party application systems. As mentioned earlier, we place in a shared folder a spreadsheet that lists people who have left the university, transferred to another department, or changed rolls. Thus, owners of third-party applications can check daily to see if access to their system must be modified. Although this is helpful, we would like to customize the report for each unit, so administrators only need to be concerned with those users who have access to their particular system.

Acknowledgments

The dedication, commitment, and patience of the following people made this project and its completion possible: Elaine Amabile, Pam Lantzy, Eric Torgersen, Christine Zoller, Steve Gatt, Eileen Macica, Andrew Stelling, Bill Taafel, Eric Dombroski, Lesile Carrole, Brian Napier, Liz Medvetz, Julie-Anne Crisafulli, Helen Strother, Denise Szelest, Kate Thies, Kathleen Botelho, Lisa Trubitt, and Chris Haile.