Manage Lync Users who used to be in Domain Admins

It’s been awhile – I’ve been transitioning into Lync administration these past few months, but ARS is still a part of that…

Today, I tried changing some of my Lync user policies, and got this:

Active Directory operation failed on “DC01234.awesomedomain.com”. You cannot retry this operation: “Insufficient access rights to perform the operation 00002098: SecErr: DSID-03150BB9, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0”.You do not have the appropriate permissions to perform this operation in Active Directory. One possible cause is that the Lync Server Control Panel and Remote Windows PowerShell cannot modify users who belong to protected security groups (for example, the Domain Admins group). To manage users in the Domain Admins group, use the Lync Server Management Shell and log on using a Domain Admins account. There are other possible causes. For details, see Lync Server 2010 Help.

But… my account isn’t in Domain Admins! It was once, for about five minutes while I attempted to prove a point, but that was several months ago.

However, that is enough to mark the account to Active Directory FOREVER AND EVER as being “special”.

Dave Simm has a post that explains what happens and how to fix it: Lync enabling or making Lync changes to a user who is or was a member of the Domain Admins security group

However, one of the commenters, Rikard Strand, points out that the inheritance fix might be automatically reverted due to the fact that adminCount is still 1.

So, here’s how you fix this with the standard AD cmdlets or ARS:

1) Find the Lync-enabled users who also have adminCount=1 – this doesn’t mean that they definitely have the inheritance issue, but that they might:

ARS: Get-QADUser -SearchAttributes @{adminCount=1;'msrtcsip-PrimaryUserAddress'="*"}

AD: Get-ADUser -LDAPFilter '(adminCount=1)(msrtcsip-PrimaryUserAddress=*)'

2) Go remove them from Domain Admins or disable them for Lync if they should stay in Domain Admins – you shouldn’t be using a Domain Admin account to run your desktop applications!

3) If they’re going to remain Lync users, fix the AD object security permissions inheritance as described in Dave’s post (dsa.msc – advanced view – Security – Advanced – check the “inherit” box)

4) Finally, set the adminCount for the users you just fixed inheritance for:

ARS: Set-QADUser -Identity AWESOME\username -ObjectAttributes @{adminCount=0}

AD: Set-ADUser -Identity "cn=username,ou=SomeCity,ou=Country,dc=awesomedomain,dc=com" -Replace @{adminCount=0}

Deprovision and UnDeprovision Users and Groups with PowerShell

Since I’ve got deprovisioning problems on the brain for some reason, here are a few little things that do work as expected.

Using Quest’s Active Directory Management Shell, connected to ARS (Connect-QADService -Proxy) as a user allowed to deprovision objects, Deprovision-QADUser works like a champ on any user who could be deprovisioned via the ARS MMC or the web interface. However, there is no UnDeprovision-QADUser or UndoDeprovision-QADUser or even Deprovision-QADUser -Undo.

There are also no cmdlets that parallel the Deprovision/Undo Deprovision functions available for groups in the ARS MMC and web interface.

The edsvaDeprovisionType and edsvaUnDeprovision attributes are accessible via the -ObjectSettings parameter of the Set-QADUser and Set-QADGroup cmdlets. So, here’s what I’ve added to my profile to remedy these slight shortcomings of the otherwise amazing QADMS:


# Makes deprovisioning groups by script similar to deprovisioning users.

function Deprovision-QADGroup {
Param($Group)

Get-QADGroup -Identity $Group | Set-QADGroup -ObjectAttributes @{edsvaDeprovisionType=1}

}

# For undeprovisioning groups. Would work the same for undeprovisioning users.

function Undeprovision-QADGroup {
Param($Group)

Get-QADGroup -Identity $Group | Set-QADGroup -ObjectAttributes @{edsvaUnDeprovision=1}

}

# Undeprovision user.

function Undeprovision-QADUser {
Param($User)

Get-QADUser -Identity $User | Set-QADUser -ObjectAttributes @{edsvaUnDeprovision=1}

}

Before you get carried away, remember that what Deprovision-QADGroup actually does is as much up to you or your ARS developer/consultant as the effects of Deprovision-QADUser are; likewise, you have to do a bit of work for what Undo Deprovision does.