Auditing Full Access Permissions

One of the nice things about Exchange Management Console (EMC) is how easy it is to grant Full Access permissions. One of the bad things about EMC is also how easy it is to grant Full Access permissions! For troubleshooting purposes or through the course of creating resource/shared mailboxes, it is often necessary to do just that - for example, it can be helpful for an admin to be able to get in to a mailbox for resetting permissions, or it can be most useful for a user (or users) to manage a resource mailbox instead of granting a lot of granular permissions. Well, because of how easy it is, it can be easy to lose track of those mailboxes to which your admin account has been granted access. Or maybe an admin is leaving and it is necessary to determine which mailboxes they granted their own account or their admin account access to to make sure no permissions remain that shouldn't. The question that I had was how to get this information - how to determine (without checking every mailbox manually via EMC) what mailboxes a specific user account had been granted Full Access to.

While researching this issue and how to get this information, I came across a lot of great sites with great information and ideas. I picked out a couple of common threads which I was able to put to use in our environment. First is Get-Mailbox, and second is Get-MailboxPermission. As mentioned above, I basically want to query all of the mailboxes for instances in which a known, specific account has been granted explicit Full Access permissions. Below is what I came up with:

Get-Mailbox -ResultSize Unlimited | Get-MailboxPermission -User [USERNAME] | where{$_.IsInherited -eq $false} | fl Identity,User,AccessRights

To break this down piece by piece, here are the different elements:

• ResultSize: this is set to "Unlimited" because we have over 1,000 mailboxes and I want to query all of them
• User: here is where I am entering the name of my administrative account (or the name of any other user who may have rights) - the brackets are not part of the actual input
• where{$_.IsInherited -eq $false}: This is the piece that will tell me if the account has been given explicit permissions via EMC - which reminds me, if you haven't become familiar with it already, make sure to read up on the "$_." trick
• fl: (a.k.a., format-list) I found these three pieces of information to be the most useful; I can see the mailbox to which permissions have been granted, I can confirm it's the user I'm checking for, and I can see if it is truly Full Access or some other combination of permissions

This can be a handy way to do some quick administrative access auditing, and hopefully this script has been helpful. As always, feel free to leave some feedback with any questions/comments!

Auditing Allowed Relays

Today's post will be a brief discussion of how to audit the systems that have been granted permissions to relay through Exchange (Exchange Management Shell > Server Configuration > Hub Transport > Relay Connector properties > Network tab > "Receive mail from remote servers..."). If your organization is like mine, you may have a pretty lengthy list of IP addresses that have been granted access (we have over 100 entries), and you may need to perform periodic audits to make sure you have a good handle on exactly what systems have the ability to send through your Exchange environment. My original research into this topic led me here, and I adapted what I found for use in our environment and made sure to understand what I was reading.

The basic process is to run an Exchange Management Shell (EMS) command to extract the desired information from Exchange, clean up the output, and then use a utility (and detective work) to figure out what hosts are behind the IP addresses. I will present the EMS command (which will probably work without any changes), but I will also go into detail about the how and why - and as always, I welcome any feedback that might help me improve on my methods.

(Get-ReceiveConnector "Relay Connector").RemoteIPRanges | fl LowerBound > C:\Temp\RelayList.txt

Piece by piece, here is what you are seeing:

• Get-ReceiveConnector: This will help you to get the name of your relay connector (which for us is "Relay Connector" - go figure!)
• RemoteIPRanges: If you perform the part of the command above in the parenthesis and add "| fl" (pipe symbol followed by "fl"), you'll get the data stored within the Relay Connector, and you'll see that the IP addresses that have been granted access are stored in the RemoteIPRanges value - unfortunately, the list may be too long for EMS to show in this simple output
• LowerBound: If you continue with connecting the dots, the output of the command leading up to the "|" (pipe symbol) will give you detail regarding the IPs in the relay list - but now we have the problem of too much information. Unless you actually granted access to a range (we did not), you just need either the LowerBound IP or the UpperBound IP (which should match since access has been granted on a per-IP basis). Pick whichever value (or both?) works for you.

Ultimately, the EMS command above gets you a text file with the list of IP addresses that have relay access, but as I mentioned, you'll need to clean up the text file by removing  all of the excess blank lines and the "LowerBound : " at the beginning of every line (Notepad++, anyone? See my previous post for further detail regarding using Notepad++ to do some of this cleanup). Now that you have a list of nothing but IP addresses, this list can be plugged into FastResolver (or your IP resolution software of choice) to get the hostnames of the systems. You will likely get several results that don't resolve, so work with your network team or do your detective work to determine what these systems are.

Finally, with all of this useful data in hand, create yourself a spreadsheet or other document to keep track of this information, and for extra credit, be good about keeping the information up to date!

Setting User Account Expiration Time

I recently handled a ticket which prompted me to revisit using the "Account expires" field in Active Directory Users and Computers (or the "accountExpires" attribute). In this ticket, it was indicated that it was very important that a user account be disabled at a specific time. I researched how the expiration field works, and found that if this flag is set, the default behavior is to expire the account at the very end of the chosen day as the clock is ready to roll over to midnight. Clearly, this wouldn't suit the requirements of expiring the account at end of business (or at any other time of the day), and I don't want to take the chance of forgetting to do it manually at the specified time.

While researching how to handle this, I came across some articles that pointed me towards a TechNet page that discusses the Set-ADUser command in the Active Directory Module for PowerShell. It turns out there's a parameter called "AccountExpirationDate" that does exactly what we need! I would recommend reading the parameter details because of how flexible it is regarding the time/date syntax it will accept, but the following command did the job for me on this particular account:

Set-ADUser -Identity [USERNAME] -AccountExpirationDate "10/05/2012 5:00:00 PM"

I'm sure I will be using this command plenty more in the future, and I hope you have found this information helpful!