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
- 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.
The post Using Skype for Business with a mandatory profile appeared first on HTG.