Tag Archives: Quest Active Directory Management Shell

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

February 12, 2013

Posted under

ActiveRoles, PowerShell

Comments

1 Comment

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.

Standard

Posted by

Posted on

October 4, 2012

Posted under

ActiveRoles, PowerShell

Comments

2 Comments

A Mystery Solved with ActiveRoles Change History

This post is a tutorial on both how to look at ActiveRoles change History and User Activity in Quest Active Directory Management Shell (QADMS) and using PowerShell to discover and extract data hidden in objects. Get-QARSOperation is the cmdlet at the heart of this.

Users are mysteriously disappearing from Active Directory, and people are casting suspicious glances your way. Whodunnit?

Fortunately for you, ActiveRoles Server keeps track of that sort of thing, as long as you’ve got Change History turned on. User object deletion is something that ARS tracks by default.

When using an initial, exploratory “Get-” in QADMS, I recommend setting a low return set size limit; here, I’ve used 5. That’s enough to pick up varied results to get an idea of what data is available, but low enough to be quick.

Get-QARSOperation -OperationType Delete -TargetObjectType User -SizeLimit 5


ID InitiatedOn InitiatedBy Status Type Target
-- ----------- ----------- ------ ---- ------

(Loads of info I don’t feel like sanitizing, so I’m just leaving it off)

Sweet!

Get-QARSOperation -OperationType delete -TargetObjectType User -SizeLimit 5 | Select-Object InitiatedBy, Target


InitiatedBy Target
----------- ------

 

(aaaand… nothing.)

Try again, this time with Format-List:

Get-QARSOperation -OperationType delete -TargetObjectType User | Format-List *


Controls : {13, AllowApproval}
ID : 1-734056
OperationGuid : 87c6ac52-07ec-43e8-abb7-1f7050ae7918
Type : Delete
Status : Completed
Initiated : 10/4/2012 12:22:30 PM
Completed : 10/4/2012 12:22:30 PM
InitiatorInfo : Quest.ActiveRoles.ArsPowerShellSnapIn.BusinessLogic.ManagementHistory.PrincipalInformationImpl
TargetObjectInfo : Quest.ActiveRoles.ArsPowerShellSnapIn.BusinessLogic.ManagementHistory.ObjectInformationImpl
TasksCount : 0

This tells us that the InitiatorInfo and TargetObjectInfo is really inside some objects. What’s in those objects?

Get-QARSOperation -OperationType delete -TargetObjectType User -SizeLimit 5 | foreach { $_.initiatorinfo | fl *; $_.targetobjectinfo | fl * }


Host : <<some pc name>>
Site : <<AD Site pc is in>>
IsDSAdmin : False
DN : <<the distinguished name of the guilty party>>
Guid : <<their GUID>>
Sid : <<their SID>>
NTAccountName : <<their NT account name in domain\username format>>
ObjectClass : user

DN : <<the distinguished name of the victim>>
Guid : <<their GUID>>
Sid : <<their SID>>
NTAccountName : (blank – ActiveRoles Server does not save this by default)
ObjectClass : user

Ok, now we’re getting somewhere. Use some calculated properties with Select-Object to pull the parts out that you want, making new PSObjects with Perp, Victim and Date properties

Get-QARSOperation -OperationType Delete -TargetObjectType User | Select-Object @{ name="Perp"; expression= {$_.InitiatorInfo.NTAccountName }}, @{ name="Victim"; expression={ $_.TargetObjectInfo.DN }}, @{ name="Date"; expression={ $_.Initiated }}

You can then write this to a CSV for future reference and Excel viewing by piping it into Export-CSV:

Get-QARSOperation -OperationType Delete -TargetObjectType User | Select-Object @{ name="Perp"; expression= {$_.InitiatorInfo.NTAccountName }}, @{ name="Victim"; expression={ $_.TargetObjectInfo.DN }}, @{ name="Date"; expression={ $_.Initiated }} | Export-CSV -Path "C:\Logs\UserDeletes-2012Oct04.csv" -NoTypeInformation

Mystery solved.