Tag Archives: Active Directory

Standard

Posted by

Posted on

February 12, 2014

Posted under

Lync/Skype for Business

Comments

2 Comments

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}

Advertisement
Standard

Posted by

Posted on

March 27, 2013

Posted under

ActiveRoles

Comments

Leave a comment

Self-Service User Can’t Add Member to Group, or Error (0x800403fb) Unknown to Anyone

The first thing you should do when you get a weird error code is plug it into your favorite search engine or, with ARS, the ActiveRoles Knowledge Base. This time, there was nothing even vaguely related to ActiveRoles Server when I tried searching for 0x800403fb, so here’s something for the next person who runs into this: the group in question has a member that ActiveRoles Server cannot directly access, and that is likely what is causing your user to have problems maintaining that group.

A Secondary Owner was getting a weird error when he tried adding a new user to one of his groups via the ActiveRoles Server Self-Service web interface. A tech at the Help Desk was getting it, too, so it got referred to me. I took a look at the group in the MMC, and it stopped listing users when it got to 1150 of them. We have some groups with over 5,000 users (I do NOT recommend this), so too many users could not have been the problem. I tried

Get-QADGroupMember ProblemGroupName -SizeLimit 0

and got after about the 1150th result:

Get-QADGroupMember : Unknown error (0x800403fb)
At line:1 char:19
+ Get-QADGroupMember <<<< ProblemGroupName -SizeLimit 0
+ CategoryInfo : NotSpecified: (:) [Get-QADGroupMember], COMException
+ FullyQualifiedErrorId : System.Runtime.InteropServices.COMException,Quest.ActiveRoles.ArsPowerShellSnapIn.Powershel
l.Cmdlets.GetGroupMemberCmdlet

So, time to look at the members list as plain strings:

$group = Get-QADGroup ProblemGroupName

$group.members
(listed a whole bunch of distinguished names without complaint)

$group.members.count

1165

Ok, so a few more than were being displayed in the GUI.

I skimmed the list until this jumped out:

CN={17656956-4661-41ad-b4dd-0a1d4ff4fccf},CN=Application Contacts,CN=RTC Service,CN=Services,CN=Configuration,DC=root,DC=hld

root.hld is our infrastructure domain, and regular users should not have anything to do with it.

RTC Service is put in the Configuration container when you first install Lync Server, and the creation date of this object aligned pretty well with when we started our Lync deployment.

So, I removed the offending object from the group:

Remove-QADGroupMember -Member 'CN={17656956-4661-41ad-b4dd-0a1d4ff4fccf},CN=Application Contacts,CN=RTC Service,CN=Services,CN=Configuration,DC=root,DC=hld' -Identity ProblemGroupName

And when I redid Get-QADGroupMember ProblemGroupName … no problem 🙂

To make sure the problem object was no longer a group member:

(Get-QADGroup ProblemGroupName).members.count

1164

The help desk tech who referred the problem to me was able to add and remove users without issues, and will be calling the user to close the ticket.