Azure AD Attribute Hide and Seek

Azure Ad Connect provides organizations with the ability to synchronize their On-premise users and groups to Azure Active Directory.  When synchronizing objects to Azure, administrators have the ability to control which users or groups are synchronized to the cloud.    Furthermore, it’s also possible to select which user or group attributes are synchronized.  Some organizations may have Security policies that prohibit certain information, such as phone numbers and addresses, from appearing in the cloud.  Luckily, attributes can be easily filtered by unchecking the attribute on the AD connector object in Synchronization Service Manager.  However, what if there’s an attribute that is being synced, but does not appear on the Azure AD connector as a filterable option?  Here’s an example that shows you how to deal with that.

Lets take a look at a user called TesterB in Powershell.  Using the Azure Powershell module (or Azure Cloud shell), we can get the user object and its properties with the following command.  Notice that the City attribute for our user is set to New York.

We don’t want location information available in Azure AD.  Lets logon to the Azure AD connect sever and open Synchronization Service Manager to filter this attribute.  Once there, click on the Connectors button.  You will see two connectors:  one for Azure AD and the other for On-premise AD.  Select the On-premise AD connector.

On the Properties window for the AD connector, click on “Select Attributes” to see the list of attributes that are available and being synchronized to Azure.

As shown below in the AD connector attributes window, there isn’t a “City” attribute.  Also, the attributes with a check mark are being synced to Azure AD.  This view shows the ldap name for each attribute, which is not always the same as its Display name, which is what the user property showed above in Powershell. To get to the bottom of this, we will need to look at the Attributes Editor for the user object in On-premise AD.

Open the TesterB user in ADUC and go to the Attribute Editor tab.  There you will see a list of the attributes that are available.  This view shows the ldap name for the attribute and its value, if one is set.  The ldap name for City is “l”, since the value is New York.

Now if you go back to the AD connector for verification, you will notice the attribute “l” is checked.  This will need to be unchecked.

Once you uncheck it and save the change, run the following command in Powershell to remove the City information from users in Azure AD and prevent it from being synced in the future.

A quick look at the City property for TesterB shows the location is no longer displayed.

That’s it!  If you ever have a situation where you can’t find an attribute to filter on the Azure AD connector, remember it probably has a ldap name that is different from the display name.





DNS Records Not Updating

I’m going to stray off of the beaten path and post a blog regarding an Active Directory DNS issue that I experienced.  Although it’s not Exchange server related, I thought this would be worth publishing as I’m sure others have encountered this issue.

We noticed that client DNS records were not getting updated in a timely manner.  More specifically, this was occurring primarily with clients that were connecting remotely to the internal network via VPN.

Suspecting that this was a client issue, one of the first measures we took was to give the DHCP servers the authority to update DNS on behalf of clients.  This seemed to alleviate the issue somewhat, however it completely resolved the problem.  Another step we took wected as to lower the DNS scavenging, where stale records would deleted sooner.  This workaround did not help matters alot either.

As I stated previously, this issue was primarily occurring with clients that connected through VPN sessions.  When client machines connect via VPN, the VPN appliance acts as the DHCP server and issues an IP address from its address pool.  There is an option within the VPN appliance to allow the internal DHCP servers to assign IP addresses, however this is probably a less secure configuration.  Once the client receives its IP address from the VPN DHCP server, the client will update its record in DNS.  Herein lies the problem.

When VPN clients update their records in DNS, they then take ownership of the records.  A look at the properties of a VPN client’s DNS record would show the client as the record owner.  When users that previously connected via VPN returned to the office, the internal DHCP servers were unable to update DNS despite having authority to do so.  The DHCP servers would need to be given permissions to overwrite records and take ownership.  This was done by adding them to the DNS Admins security group.  Afterwards, the DHCP servers were now able to update DNS records that were owned by clients that previously connected via VPN.