- Provisioning UMROOT Active Directory Accounts
- Services that Use Active Directory
- De-Provisioning UMROOT Active Directory Accounts
- Tips for System Administrators: Managing UMROOT Accounts
MCommunity data is used to provision and de-provision Active Directory (AD) UMROOT accounts through a real-time data feed from MCommunity to UMROOT Active Directory. Members of the U-M community automatically get AD accounts when their uniqname is created and lose access when they are no longer eligible.
MCommunity groups and AD. MCommunity groups used to provide administrative access to services ordered through the Michigan IT Services Portal are synchronized to Active Directory (UMROOT).
Members of the U-M community get a UMROOT Active Directory account automatically when they get their uniqname.
Some additional information comes through from MCommunity to Active Directory for people whose directory profiles are designated as private. The person's title (U-M working title), affiliation, and U-M work phone are visible inside Active Directory.
These services require an Active Directory account:
- MiWorkspace computers
- ITS Exchange email, calendaring, and Unified Messaging voicemail—Ann Arbor campus (this does not affect the Exchange service provided by Michigan Medicine)
- Campus Computing Sites—Ann Arbor campus (An Active Directory account is required for access to Sites computers, but login is done via pass-through Kerberos authentication rather than by using the Active Directory password.)
- U-M SharePoint Portal
- ITS Mainstream Storage—Ann Arbor campus
- Desktop Backup (CrashPlan)—Ann Arbor campus
- Departmentally provided computing services on the Ann Arbor campus that use UMROOT Active Directory passwords for login
- Department and lab computers on the Dearborn campus
No Affiliation, No UMROOT Account
When people lose all affiliations with the university, they lose eligibility for a UMROOT Active Directory account; their account will be de-provisioned.
- Many of the people who lose eligibility will be terminated faculty and staff. Terminated faculty and staff who have no other university affiliation begin the Active Directory de-provisioning process when their affiliation is removed from Wolverine Access and therefore from their MCommunity Directory profile. They get 30 days notice before losing access to services that use their UMROOT account. Faculty and staff who retire keep their accounts.
- Students who drop out before completing their first term lose eligibility for UMROOT accounts. They begin the de-provisioning process when they no longer have a student affiliation. They get 30 days notice before losing access to services that use their UMROOT account. Students who become alumni keep their accounts.
- Sponsored people lose their Active Directory account when their sponsorship expires. The person who sets up their sponsorship can request that the sponsored person and others receive notice when the sponsorship nears expiry. Otherwise, no notice is sent.
People with any one of these affiliations are eligible to have UMROOT Active Directory accounts: faculty, staff, retirees, students, alumni, and sponsored people.
What Happens When?
- Day Zero—Notification sent. On the day a person loses their faculty or staff (unless they become a retiree) or student (unless they become alumni) affiliation in their MCommunity Directory entry, MCommunity will send them an email message notifying them that they will lose access to some computing services in 30 days. Please note that sponsored affiliates do not get the 30-day grace period. They lose access to all U-M computing services when their sponsorship expires.
- Day 30—UMROOT account disabled, person removed from groups. Thirty days after the Day Zero message is sent, the UMROOT Active Directory account is disabled. The person will no longer be able to log in with their UMROOT Active Directory password. The account will be re-enabled if the person gets a new affiliation with the university (faculty, staff, student, or sponsorship). Also on Day 30, the person will be removed from all groups in the UMROOT Active Directory.
- Day 60—ITS Exchange account removed. If the person had an Ann Arbor campus ITS Exchange mailbox (email, calendaring, Unified Messaging voice mail), that mailbox will be kept for 30 days after the account is disabled to allow for restoration if needed. After that, the mailbox will be removed, and it will no longer be possible to restore it. (Note that Michigan Medicine uses an Exchange/Outloook email service that is different from the ITS Exchange Service. Michigan Medicine Exchange is not affected by UMROOT Active Directory de-provisioning.)
- UMROOT account deleted. When the person's entry is deleted from the MCommunity Directory, their Active Directory UMROOT account will be deleted. Terminated faculty, staff, and students who do not complete their first term remain in the directory for a little over a year. See Leaving U-M for details about when people lose their directory entry.
- To get an Active Directory account for someone who does not get one by virtue of becoming an employee or student, sponsor them through the MCommunity Sponsor System. You can ask your departmental sponsorship administrator or the ITS Service Center to set up the sponsorship. The Service Center can tell you if your department has a sponsorship administrator.
- Departments must manage their sponsorships. Every sponsorship has an expiry date; the maximum length is one year, and sponsorships can be renewed as needed. If you want a person sponsored by your department to continue to have Active Directory access, do not let their sponsorship expire.
- U-M Active Directory unit administrators can continue to create user objects in their Organizations OU. Remember that you cannot create user objects with uniqnames or using the uniqname naming conventions (3-8 alphabetic characters for regular uniqnames and the letters "um" followed by a six-digit number for temporary uniqnames). Objects in the Organizations OU will not be affected by the MCommunity data feed.
- IMPORTANT! Having a UMROOT Active Directory account allows people to authenticate. Unit administrators must then determine whether people who can authenticate are entitled to use the resources they provide—that is, are they authorized? Unit administrators should check to be sure that people are covered by the relevant software agreements before providing resources to them.