De-Provisioning a Lync User

The word ‘de-provision’ doesn’t show up in many dictionaries, but it is an important word for IT shops.

For Microsoft Lync Administrators it typically refers to performing two actions on an existing Lync user: disabling access to Lync and then removing the resources associated with that users Lync account. The common use-case for doing this is if an employee leaves or is terminated.

De-provisioning a Lync user can be accomplished in several ways. This blog post covers the pros and cons of the various known methods. Some of this has been discussed in the community before, but I wanted to present my experience with several options for the benefit of others.

Disabling the Associated AD Account

De-provisioning a user is easy right?

When an employee ceases employment at a company, most Lync deployments simply disable the Active Directory user associated with the Lync account. However, in Lync Server this does not disable the users ability to use Lync while they are currently logged on (e.g. to their Windows workstation with a Lync client), and further, it will likely not prevent the Lync user from signing back into Lync again either (while authenticated to the domain). Here why:

• Lync Server 2010 authentication leverages Kerberos and NTLM authentication for sign-in by default.
• If the user selects the “Save my password” checkbox on the Lync client sign-in dialog, the user is sent an X.509 certificate generated by the Lync server.
• This certificate by default is good for 180 days, so even if the AD account is disabled, the user can still sign-in to Lync (worst case for up to 180 days). The certificate is stored in the user’s Personal Certificate Store.
• The employee is also able to continue to use the full Lync functionality on any active session.
• This holds true for any Lync deployment using Kerberos and NTLM authentication with client certificates.  Remote users and domain-joined users with a valid certificate with be able to access Lync.

Microsoft Exchange MCM and MVP Jeff Guillet has a really good article that includes more information on this. 

In this post, I explore what options are available to de-provision a Lync account, and explore the pros-and-cons of each.

Before we get to that, what exactly does disabling the AD account do in terms of Lync functionality then?

The short answer: nothing. Disabling the AD account of a Lync user has no immediate affect on the associated Lync user functionality:

1. The AD attribute msRTCSIP-UserEnabled is unaffected.
2. The Lync “Enabled” attribute (as shown in the Lync Control Panel, and the Get-CsUser, Get-CsAdUser cmdlet’s) is unaffected.

This reinforces the Golden Rule for Lync user provisioning starting in Lync Server 2010: after the based user AD account is provisioned settings related to a Lync user should be changed through Lync, not AD, even if similar AD attributes exist – a lesson learned previously for provisioning Federation and Remote Access: Configuring User Federation, Remote Access, and Public IM in Lync.

Possible Solutions

Here are my experiences with the methods available to de-provision a Lync user account.

1] Disable the Lync User using Disable-CsUser

A common recommended solution is to use the Lync Disable-CsUser cmdlet. The big advantage of this method is that it prevents users from using Lync Server, and more importantly disconnects any active Lync sessions as shown in this example of an active Lync user being disconnected:

Tip – it will take a few minutes for a signed-in user to become disconnected however they will be unable to access any Lync features, such as new IM, web conferencing, or Enterprise Voice calls while they are signed in.

The major disadvantage of this method is that is it deletes all the attribute information related to Lync Server from the AD user account, Lync settings such as policy assignments, and all Lync user data (including the users’ contact list and any scheduled conferences). 

On the surface this sounds fine since we want to get rid of the Lync account anyway, but corporate provisioning ‘systems’ (everything from homegrown scripts to solutions which integrate HR systems and Active Directory) have been known to have bugs and will inadvertently disable users that should not be. Using Disable-CsUser makes it impossible to easily restore the Lync user account to what it was!

For this reason, if there is any doubt that the Lync user account should not be fully removed, the better option is to use the Set-CsUser cmdlet instead – which is discussed in the next section.

Tips:

1. I have found that the disabled Lync user will remain on the contact lists of other Lync users once the account is restored with Enable-CsUser.
2. You can quickly re-enable the Lync account with Enable-CsUser (but the Lync account will be equivalent to a new account with no contact lists, policy settings, etc…).  Enable-CsUser requires 3 parameters:  Identity, SIP address, and home registrar as in this example:

   Enable-CsUser -Identity ExampleUser@domain.com -SipAddress sip:ExampleUser@domain.com –RegistrarPool LyncPool.domain.com

2] Disable the Lync User using Set-CsUser

If we want to keep the Lync user account intact but disable it, use the Lync cmdlet: Set-CsUser. Unlike Disable-CsUser, the Set-CsUser can easily be reversed by setting the $Enabled parameter to $True – the user contact lists, scheduled conferences, and Lync settings stay intact as they were.

The big disadvantage to this method is that any current Lync sessions stay active – the user is not disconnected. So the question becomes, what functionality are they able to use during that active session after they have been disabled using this method?

Here are my experiences:

1) Presence, IM, and Conferencing is available for up to 5 minutes

2) Within 5 minutes of the user being disabled:

• The user appears to remain signed in, however,
• The user cannot use any Lync communication features. Any attempts to IM result in an error message like this:

3) Any attempt to Conference (or Meet Now) generates an error, like this:

4) Attempts to initiate an IM with a disabled Lync user are rejected.  The user appears offline to the caller.

Important: my initial attempts at disabling the user with Set-CsUser were not good – the disabled Lync user could still IM, Conference, etc.. in their active session.  I attributed this to either unpatched Lync 2010 Clients, or not waiting long enough for the disable action to be effective. Suffice to say if you are running the the Lync 2010 Client make sure it has the most up-to-date hotfixes installed.

Tip -  the $Enabled parameter on this cmdlet is the same setting used by the Lync Control Panel to disable a Lync server user. It also corresponds to the AD attribute msRTCSIP-UserEnabled, but again it should be set through the Lync cmdlet’s or the Lync Control Panel, not through AD. I point that out because some provisioning systems still use AD only.

3] Revoke the Lync Client Certificate

As Jeff Gulliet points out in his article, you can revoke the client certificate used for authentication by using the Revoke-CsCertificate cmdlet which will disable the ability to sign-in to Lync. After about 3 minutes revoking the certificate, the user will receive this error message when they try to sign back into Lync:

The disadvantage is that will not affect the users current active Lync session, and it will not restrict Lync functionality during that session. I tried this myself, and indeed the Lync user can IM, conference, and use other Lync features.

Also, I have not found an good method to restore the certificate once it is revoked, which makes reversing this change difficult.

4] Change the SIP Address to Something Invalid

While this option initially seemed absurd, it had it’s advantages: the Lync user would not be able to sign-in again and it is easily reversed if there was a mistake.

You have two options here: change the left-hand-side (LHS) of the SIP address, or the right-hand-side (RHS) which is the FQDN.

Neither the Lync Control Panel or Lync PowerShell rightfully allows a setting on the right-hand-side to a domain that is not supported in the Lync deployment, so this is not an option.

You can change the LHS (the username part of the SIP address) using the Set-CsUser cmdlet with the –SipAddress parameter.

Surprisingly, this worked! And better yet, the Lync user is actually disconnected immediately as shown below.

Also, the change was easily reversed by using the Set-CsUser cmdlet to change the SIP address back to it’s original.

While this seems to work on the surface, here are some points to consider:

• The disabled Lync user could still sign-in with the new SIP address if they are clever enough to figure-out what the new SIP address is, so use in conjunction with disabling the Lync account with the Set-CsUser method.
• Programmatically finding a SIP address that is absolutely not already in use could be a challenge (although you should be safe appending something like “123456” onto the end of the LHS of an existing SIP address.
• It can lead to confusion – the SIP address is now disjoint from the user principal AD account.
• Be sure to fully de-provision the account at a later time using the Disable-CsUser cmdlet to clean up the resources.
• If the change is reversed and the SIP address is changed back to what it was, in my testing, other Lync users will be required to sign-out and sign-back in again to see the restored Lync users presence.

Caveat Emperor: I haven’t fully vetted this solution in a production environment, only in a lab. It does appear to be effective though and could be tested further if you have a need to disconnect the Lync user immediately.

If your provisioning system still only has access to AD (and not PowerShell – yikes!) this could be your best option.

Recommendation

Unless you have a need to disconnect the active Lync session immediately, I believe a two stage process using Set-CsUser and Disable-CsUser is the best.  Disable the Lync user with the Set-CsUser cmdlet (or the Lync Control Panel) first, and then after some safe amount of time fully de-provision the Lync account with Disable-CsUser.

Below is a quick Lync Management PowerShell script that you can use to identify AD accounts that are disabled but have a corresponding Lync user account that is still enabled – a situation you probably want to avoid for security reasons:

Write-Host
Write-Host "Lync enabled accounts that have disabled AD accounts:"

Foreach ($LyncUser in Get-CsAdUser)
{
    Foreach ($value in $LyncUser.UserAccountControl)
    {
        if ($value.ToString() -like "AccountDisabled*")
        {
            if ($LyncUser.Enabled -eq $True)
            {
                Write-Host "  > " $LyncUser.Name " (" $LyncUser.SipAddress ")"
            }
        }
    }
}

Powershell guru’s will note this can be done on one line 🙂 but I put it into loops so people can easily modify it.

References

• The EXPTA Blog: Disabling a User in AD Does Not Disable the User In Lync
• Microsoft NextHop: Lync 2010 Client Authentication