Restrict or filter GAL access for OWA users using MSExchQueryBaseDN in Exchange 2007

January 9, 2012 Leave a comment

When hosting Exchange 2007 mailboxes for use purely with Outlook Web Access (OWA) you may wish to limit access to the Global Address List (GAL), so that logged in users can only see a subset of the contacts in the GAL. This would be particularly relevant in hosting environments where mailboxes may be hosted for multiple companies in the same active directory, and you might want users to only see contact information from users for their company, rather than all companies.

A while ago we had a situation where this was a requirement. In our case there were several groups of users who would only be accessing email through OWA, and only needed contact information for a subset of staff. We were able to use custom address lists and the MSExchQueryBaseDN user attribute to solve this problem.

If you run adsiedit.msc and look at the properties of a user object you can scroll down the list of attributes to find MSExchQueryBaseDN.

The MSExchQueryBaseDn attribute in adsiedit

In order to limit which contacts a particular user or group of users can access, firstly you need to set up a new Address List either using the Exchange Management Console, or Exchange Management Shell. The address list should contain the contacts that you want the user or group of users to be able to view. Please note that you could point the MSExchQueryBaseDN attribute to an Organizational Unit, so it would filter contact information for just the users in that OU, but if you need the flexibilty to include contact information for users from various OUs in active directory, it may be easier to use a custom address list.

Once this is done you need to set the MSExchQueryBaseDN attribute of each of the users who you want to restrict to the distinguished name of the address list you created.

e.g.

CN=YOUR_RESTRICTED_ADDRESS_LIST,CN=All Address Lists,CN=Address Lists Container,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=YOUR_DOMAIN,DC=local

Where YOUR_RESTRICTED_ADDRESS_LIST is the name of your address list and YOUR_DOMAIN is the name of your domain.

Obviously it would be too time consuming to set this attribute manually for hundreds of users so you could either use ADModify if you want to use a GUI:

Set MSExchQueryBaseDN using ADModify.Net

To reset to the default value using ADModify.Net use a value of ‘null’.

You could also use  to achieve this in Powershell if you would prefer to use the command line. Further details can be found here.

Please note: Using this attribute in Exchange 2010 SP1 may result in undesirable consequences. It has been reported that if this attribute is used you may find that users with the attribute set cannot view the contents of their address list, particularly in Outlook.

Filed under Active Directory, Exchange Tagged with , , , ,

Export a list of members from an Active Directory group to a text file

January 6, 2012 20 Comments

I needed to export a list of all the members in an active directory group today. Here are two methods which work well. The first example uses the net group command. In both examples ‘Group Name’ is the name of the group that you want to export the member list for, and memberlist.txt is the name of the output file.

net group “Group Name” /domain > memberlist.txt

The second example uses dsquery and dsget, which will return the full distinguished names of the user objects that are members of the group. This could be useful if you also need to know which organizational unit the members accounts reside in.

dsquery group -name “Group Name” | dsget group -members > memberlist.txt

Filed under Active Directory, General, Windows Tagged with , , , ,

Force KCC (Knowledge Consistency Checker) to run on a domain controller

January 5, 2012 Leave a comment

Sometimes after demoting domain controllers you may be left with inconsistent NTDS connection objects in Active directory. In my case there was an NTDS connection object listed under one of the domain controllers at our central site which referenced a recently demoted domain controller at a remote site. I needed an NTDS connection object pointing pointing to the newly installed DC at the remote site instead. To fix this i simply deleted the incorrect NTDS connection object in the ‘Sites and Services’ console, from the central site domain controller, and then forced KCC to run on the same domain controller by running:

repadmin /kcc

This forces the domain controller that you run the command on to check its inbound replication topology immediately and generate any missing connections. After running this command a new NTDS connection object was generated from the new DC at the remote site. This can either be verified by checking under the Domain Controllers NTDS Settings, in the ‘Sites and Services’ Console or by running:

repadmin /showrepl

Filed under Active Directory Tagged with , , , , ,

← Older posts

Newer posts →