The Enterprise Eightfold Path

Using Skype for Business with a mandatory profile

The Enterprise Eightfold Path

Using Skype for Business with a mandatory profile

By James Rankin   |     Friday 13 October 2017

Tags:

I’ve had some email comments recently regarding Skype For Business 2016 with mandatory profiles. When you use Skype for Business and log in for the first time, it needs to install a personal certificate into the user profile. As those of you who have used mandatory profiles before will know, personal certificates can’t be used in mandatory profiles, as they are not intended to be shared. This means that users with mandatory profiles trying to use for Skype for Business will be unable to sign in.

Technology like Ivanti DesktopNow and Ivanti RES used various methods of profile spoofing to avoid this issue, but for simple implementations, adopting third-party technology isn’t really an option. People who use mandatory profiles for kiosk or access area machines may well want to give the users the option to sign into Skype for Business, but also to purge the profile from the machine at log off.

There have been a couple of articles I have seen referenced by Microsoft with regard to this issue, but there is no solution offered (see this article for an example). However, it is possible to use Group Policy to achieve this.

The Windows operating system gets the profile type from a Registry value called State stored in HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\[SID] (where [SID] equals the security identifier of the user). If the State is detected as a DWORD decimal value of 5, it (usually) indicates a mandatory profile. By manipulating this value using logon and logoff scripts, we can trick the operating system into thinking the profile is non-mandatory during the session (and allowing the Skype for Business certificate to be installed), but also purge the profile at logoff because the operating system sees the profile as mandatory again. There are a few steps needed to achieve this

  1. Set the ACLs on the \ProfileList key

Users need to be given access to the ProfileList key in the Registry. The easiest way to do this is to use a Group Policy Object to set permissions for Authenticated Users. Set up a GPO and set the values under Computer Configuration | Windows Settings | Security Settings | Registry to the below

KEY – MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Once this GPO is applied and propagated, you should see Authenticated Users have Special permissions to that Registry key.

2. Ensure “Logon script delay” is set to 0

This is the bit I missed out of the video and had to append to the end 🙂 From Server 2012 and up, logon scripts don’t run at logon, they run five minutes afterwards (yes, I know). So set the delay to 0 via Group Policy to make your logon scripts run when you expect them to. The policy is in Computer Config | Admin Templates | System | Group Policy and is called Configure Logon Script Delay, set it to 0.

3. Set up a GPO with logon and logoff scripts

You need to set up two PowerShell scripts, one for logoff and one for logon, and apply them via a Group Policy Object. The logon script should look like this:-

$USERSID = ([Security.Principal.WindowsIdentity]::GetCurrent()).User.Value
set-variable -Name key -Value “HKLM:\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\$USERSID”
$state = (Get-ItemProperty -Path $key -Name State).State
if ($state -eq 5) {Set-ItemProperty -Path $key -Name State -Value 9000}

The script reads the user SID, reads the State value from the user, and if it is equal to 5, changes it.

Note we are setting the State value to 9000. The OS will still interpret this as non-mandatory, but it will be a specific value that couldn’t happen by accident. This is to ensure that when we are resetting the profile to mandatory at logoff, we don’t accidentally run it on a profile that wasn’t mandatory to begin with. Checking for this unusual value (9000) will make sure it only resets on accounts we’ve already changed.

The logoff script is very similar and should look like this:-

$USERSID = ([Security.Principal.WindowsIdentity]::GetCurrent()).User.Value
set-variable -Name key -Value “HKLM:\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\$USERSID”
$state = (Get-ItemProperty -Path $key -Name State).State
if ($state -eq 9000) {Set-ItemProperty -Path $key -Name State -Value 5}

Essentially it is just working in reverse, checking the State value and if it is 9000, resetting back to 5.

4. Deploy and test

Once these GPOs propagate, a user logging on with a mandatory profile should be able to use Skype for Business without getting a certificate error. I have recorded a video of the process in action here.

Comments

One response to “Using Skype for Business with a mandatory profile”

  1. Frank Anderson says:

    Great post James! There’s another thing to consider with Skype for Business especially around end-user computing solutions. The personal/user certificates issued by the SFB server are limited to 16 per user and are bound to the device as part of the cert chain. You can see how using a floating assigned, non-persistent VDI pool (or Delivery Group) could have an impact when USB desktop phones, or similar devices, are in place that also use those certs. Once the 17th cert is issued the oldest gets revoked which will cause users to have to manually login to the telephony device such as a USB desktop phone. MS is aware of this and currently working on a solution. The workaround is to use dedicated desktop pool entitlements for now – can be non-persistent (Instant Clones, Linked Clones, PVS, MCS), but needs to be the same virtual desktop every time.

Leave a Reply

Your email address will not be published. Required fields are marked *

Join our mailing list

Sign up for our newsletter today and we'll send you exclusive content including free guides and articles. We promise not to send you spam and we don't share your details with anybody else.

Contact us

Howell Technology Group
One Trinity Green
Eldon Street
South Shields
NE33 1SA

T. 0191 4813446

Email us

Cookies policy

The HTG website uses cookies to store information on your computer. By continuing to browse this website you are agreeing to our use of cookies. Learn more

Accept

Thank you - you've accepted our cookies policy.