Applying inherit rights (inheritable) for permissions to a large number of Active Directory objects

I was recently involved in a project to help secure a School’s Active Directory environment.  After sitting down and planning what we wanted to achieve in terms of account security we went to work.  After setting up all of the IT based security groups and assigning and delegating the appropriate rights and permissions we found that somethings wern’t working as they should.  The permissions gave us the rights to do what we needed on the Student user objects but not on the staff.  After taking a quick look we found that the majority of Staff didn’t have their inherit permissions from parent ticked, which prevented the delegation from flowing through to these user objects.

Looking at PowerShell there are Get-ADUser and Set-ADUser which allow us to get and set certain properties on user objects but still didn’t allow us to set inherit rights on objects.  I then happened to stumble upon a management pack of PowerShell scripts from Quest Software which are available from this link. The pack contains some useful scripts which extend on the original Microsoft provided scripts.  The pack also contains a PowerShell cmdlet dealing specifically with Object Security which is what we are after. So I went ahead and downloaded the 64 bit version to one of the domain controllers (after testing it out myself) and worked out we needed to filter for users who didn’t have the inherit permissions enable. The following is a snippet which will list all of the users in your AD environment with inherit permissions disabled (watch the word wrap):

Get-QADUser -SizeLimit 0 |
Where-Object {$_.DirectoryEntry.psbase.ObjectSecurity.AreAccessRulesProtected}

If you are after a particular Organizational Unit simply replace -SizeLimit 0 with -SearchRoot ‘Distinguished name of OU’.

Now we are able to find the users, but what about setting the inherit right.  Using the ObjectSecurity cmdlet we can now set the Inheritance flag. So the following is the complete command to run on l (again, watch the word wrap):

get-QADUser -SearchRoot 'Distinguished Name of OU' |
Where-Object {$_.DirectoryEntry.PSBase.ObjectSecurity.AreAccessRulesProtected} |
Set-QADObjectSecurity -UnLockInheritance

After running that cmdlet on the offending User Objects, we were then able to successfully do what the security groups allowed us to do. I still need to go back and check out what else the pack from Quest can do as I looked quite interesting so I will be sure to blog about my findings.

When viewing Public Folders in Outlook you recieve the following error, Cannot expand the folder. Microsoft Exchange is not available.

So there have been quite a few posts about Exchange 2010 lately, I guess it’s mainly because that has been my focus for the last few months at my current job. So here is another one regarding an error message when you try to access public folders in outlook and how to fix it.

We were receiving calls that users were unable to access their public folders (which contains our global calendar) We were able to replicate the issue on our own accounts and received the following message.

Cannot expand the folder. Microsoft Exchange is not available.
Either there are network problems or the Exchange server is down
for maintenance. (/o=First Organization/ou=Exchange
Administrative Group (DOMAIN)/cn=Configuration/cn=Servers/cn=SERVERNAME

So we quickly remoted into our server which published our Public Folders, started the public folder tool and could see them all there, also running the get-publicfolder PowerShell cmdlet ran and listed all of the available public folders.  I then decided to take a quick look at the services which were running.

Public Folders are pushed to Outlook clients via Microsoft Exhcnage RPC Client Access Service, and if stopped you are unable to browse for public folders and get the above error.  In our case we were able to simply start the Service and the Public Folders were vieable in Outlook again.  I’ve heard of some isntances where the service no longer starts, if that is the case then you may need to check on permissions in the Bin folder inside Exchange.