Category Archives: cloud

Attribute Uniqueness in Azure Active Directory

Posted on by

As I dive deeper into Azure Active Directory, I am learning quickly that AAD is a very different animal than on-premises Active Directory Domain Services (AD DS). While both solutions provide identity, authentication, and authorization services, they do so in very different ways. These differences require organizations to be prepared to adjust standard processes to get the two services to work together. Today I will focus on the identity portion of the solution and how the different attribute uniqueness requirements in AAD and AD DS can introduce the need for evolution of management processes for AD DS.

The attributes I want to focus on are userPrincipalName, proxyAddresses, and mail. In AD DS userPrincipalName is a single valued attribute, proxyAddresses is a multivalued attribute, and the values included in those attributes must be unique to the object in the forest. The mail attribute (the attribute that populates the E-mail field on the General tab of Active Directory Users and Computers (ADUC)) is a single valued attribute that doesn’t have a uniqueness requirement. In AAD all three attributes retain their single value or multivalued properties, however, the uniqueness requirements change considerably.

AD DS allows these values to be duplicated across different attributes. For example, one object could have a userPrincipalName of john@contoso.com and another object could have a value in its proxyAddresses attribute of SMTP:john@contoso.com. The same goes for an object that has a mail attribute of john@contoso.com and another object has a value in its proxyAddresses of john@contoso.com.

In AAD this is no longer true. User, group, and contact objects synchronized to AAD from AD DS require the userPrincipalName, proxyAddresses, and mail (also targetAddresses if you’re using it) to be unique among all objects in the directory. This means that each of the scenarios I discussed above will create synchronization errors. You can’t have one user object with a value in the proxyAddresses of john@contoso.com and another use object with mail attribute of john@contoso.com.

What happens if you do? Well, let’s make it happen. In this scenario we have two user objects with the configuration below:

Object 1
userPrincipalName: jess.felton@journeyofthegeek.com
proxyAddresses: SMTP:felton@feltonma.com
Sync Status: Already synced to Azure AD

Object 2
userPrincipalName: matt.felton@journeyofthegeek.com
proxyAddresses:
mail: felton@feltonma.com
Sync Status: Not yet synced to Azure AD

After we force a delta synchronization of Azure AD Sync, the errors provided below pop up in Synchronization Manager and an email alert:

Screen-Shot-2016-06-05-at-8.07.18-PM.png

Screen-Shot-2016-06-05-at-8.08.24-PM

The net result of the above matt.felton@journeyofthegeek.com won’t synchronize correctly to AAD and the user will be unable to authenticate to AAD. How about two user objects with the same mail attribute? That’s a common use case, right? Nope, same issue. Take note that just because you receive an error saying the issue is with a duplicate value in the proxyaddresses attribute, it could be the userPrincipalName, mail, or targetAddress of another object in AD DS.

Small differences like this can lead to major changes in how organizations manage AD DS when they begin their journey into AAD. The key take away here is to understand that AD DS and AAD are not the same thing, the differences need to be understood, and you must be prepared to evolve existing processes if you wish to leverage the solution.

I’ll end this with a thank you to Jimmie Lightner from MS for his blog post that brought light to this issue many months ago. You can read that post here.

P.S. Take note that if you opt to an alternate login ID (separate attribute from userPrincipalName for user identifier in AAD), the uniqueness will carry over to that attribute as well.

Azure Active Directory Connect – Behind The Scenes – Part 2

Posted on by

Today I will continue my series of blog posts on Azure Active Directory Connect. In today’s entry I will cover the database backend that powers the Azure Active Directory Sync portion of the AADC solution.

AADC supports both a full-fledged version of SQL running on a dedicated server or a localized database that is installed automatically during the initial installation. The decision as to which to use depends on the number of objects in the on-premises Active Directory environment that AADC will synchronize from. I will focus in on the localized database.

My first assumption was that Microsoft would use a Windows Internal Database (WID) solution for the backend, as they do with server roles like Active Directory Federation Services (AD FS) and Active Directory Rights Management Services (AD RMS). Instead Microsoft has chosen to use a version of Microsoft SQL server called Microsoft SQL Express LocalDB. You can think of LocalDB as the middle ground between MS SQL Compact and MS SQL Express in terms of functionality and use case.

So we know the version of SQL, but how do we connect to it? Is it a named instance?

Try as I may I could not find an Azure AD Connect PowerShell cmdlet that provided me with the connection string information. My next stop was the registry. As luck may have it, I found the information in HKLMSYSTEMCurrentControlSetServicesADSyncParameters as seen in the screenshot below.

Screen-Shot-2016-06-04-at-8.47.22-PM.png

The registry keys we are interested in are the Server, SQLInstance, and DBName. These entries indicate that the instance is running on the local server, the instance name is ADSync, and the database is named ADSync. This provides enough information to connect to the database using SQL Management Studio. We’ll use this string (localdb).ADSync to connect to the SQL instance.. This took me a while to put together because the (localdb) portion is specific to SQL Express LocalDB.

After we connect to the instance we can further explore the databases (if we are so inclined). Many of the databases are self-explanatory and don’t require further discussion. I did find it interesting as to the structure of the data for the synchronization rules in the synchronization_rule field within the dbo.mms_synchronization_rule table. I’m also curious as to the how the passwords for the management agents are encrypted prior to being base-64 encoded in the encrypted_configuration field in the dbo.mms_managmenent_agent table.

In the next post I’ll take a look at the API the Azure AD Connector uses to synchronize information to Azure Active Directory.

Thanks!

Azure Active Directory Connect – Behind The Scenes – Part 1

Posted on by

Hi all,

I promised to deliver some behind the scenes blogs on Azure Active Directory Connect. I will be delivering on that promise through a series of blog posts that will explore the functionality of the tool that isn’t well documented (if at all documented) by Microsoft. Our first stop in the journey will be exploring how the Azure Active Directory Sync tool handles synchronizations to and from Active Directory Domain Services (AD DS).

The Azure Active Directory Sync component of Azure Active Directory Connect is built from the same framework as Forefront Identity Manager (now called Microsoft Identity Manger (MIM)). This means the connector for AD DS is very similar (possibly a direct port) of the connector used in MIM. So that means all the documentation for this connector is heavily documented with the MIM documentation right? Oh no no no no. What little documentation that does exist for MIM is at the sub-100 level (really Microsoft?). This means we have to be a bit creative in figuring out exactly how the connector is pulling for changes.

I had heard on the grapevine that the AD DS connector uses the uSNChanged method of querying for directory changes as outlined in the following link. To verify this I setup a small lab with a domain controller and a server running Azure Active Directory Connect (AADC going forward). Like any good AD engineer, I cranked up Field Engineering logging on the domain controller per this link. To my surprise, I saw didn’t see any LDAP queries from my AADC server.

My next step was to do some network captures with Wireshark. During the capture I saw the LDAP traffic coming in encrypted via a TLS tunnel. Foiled yet again… or was I? Thankfully Azure Active Directory Sync has an option where encryption of LDAP traffic can be turned off. This is accomplished by opening the Synchronization Service application on the AADC server, navigating to the Connectors tab, right-clicking the Active Directory Domain Services connector, selecting Properties, select Configure Directory Partitions selection, and clicking the Options button. Uncheck both options as seen in the screenshot below. Once encryption is turned off, the LDAP queries can be read.

Screen-Shot-2016-06-02-at-8.49.54-PM

When we dig through the capture we see the following LDAP query coming from the AADC server:

baseObject: dc=journeyofthegeek,dc=local
Scope: substree
Filter: (&(|(objectClass=computer)(objectClass=contact)(objectClass=container)(objectClass=domainDNS)(objectClass=foreignSecurityPrincipal)(objectClass=group)(objectClass=inetOrgPerson)(objectClass=msDS-Device)(objectClass=organizationalUnit)(objectClass=user))(!(objectClass=groupPolicyContainer))(!(objectClass=msDS-GroupManagedServiceAccount))(!(objectClass=msDS-ManagedServiceAccount))(!(objectClass=msExchConfigurationContainer))(!(objectClass=msImaging-PSPs))(!(objectClass=msPKI-Key-Recovery-Agent))(!(objectClass=rpcContainer))
Attributes: Reference to this link.
Controls:

    • ControlType: 1.2.840.113556.1.4.417 (LDAP_SERVER_SHOW_DELETED_OID)
    • ControlType: 1.2.840.113556.1.4.529 (LDAP_SERVER_EXTENDED_DN_OID)
    • ControlType: 1.2.840.113556.1.4.2065 (LDAP_SERVER_SHOW_DEACTIVATED_LINK_OID)

<liControlType: 1.2.840.113556.1.4.841 (LDAP_SERVER_DIRSYNC_OID)

The query above is a fairly basic LDAP query. The controls are what we are interested in. Let’s walk through the first three controls quickly.

  1. ControlType: 1.2.840.113556.1.4.417 (LDAP_SERVER_SHOW_DELETED_OID)Quick Explanation: This control tells the directory to return deleted objects that match the query filter.
    More Detail: Link
  2. ControlType: 1.2.840.113556.1.4.529 (LDAP_SERVER_EXTENDED_DN_OID)
    Quick Explanation: This control tells the directory to return the DN preceded by the objectGUID and objectSID in string format.
    More Detail: Link
  • ControlType: 1.2.840.113556.1.4.2065 (LDAP_SERVER_SHOW_DEACTIVATED_LINK_OID)
    Quick Explanation: When used in combination with LDAP_SERVER_SHOW_DELETED_OID, it also returns link (forward/backlink) attributes on deleted object.
    More Detail: Link

The fourth control is the most important piece of the query, so let’s spend some time on it. Active Directory Domain Services provides a few different methods for an application to stay updated on the changes within the directory backend. Three of those methods are change notifications, the DirSync control, and the USNChanged. We are going to focus on the DirSync control, but information on the two other methods can be found here.

The DirSync control allows an application to keep track of changes in the directory by utilizing a piece of data that contains information about the state of the directory as the application last knew it. AD DS puts this of data into a cookie which is updated by the directory each time the application requests a synchronization from the directory. During the initial request (the Full Import run profile in Azure AD Sync) the cookie contains a null value which instructs the directory to return all objects and attributes that match the filter. The directory places a value in the cookie during this initial request. For subsequent requests (the Delta Import run profile in Azure AD Sync) the value of the cookie is used to determine which objects and attributes have changed since the last sync and only that information is returned to the application. The cookie is updated during each subsequent request.

I noticed the connector using the DirSync control I was a bit confused, because much of the documentation out on the web states there are specific permissions and rights required by the identity used by the application in order for that identity to be authorized to leverage the control. After a lot of searching through the web and reading forums, I came across an archived version of an MSDN link that had this interesting piece of information:

LDAP_DIRSYNC_OBJECT_SECURITY (OS): Server 2003 operating system, Windows Server 2008 operating system, Windows Server 2008 R2 operating system, Windows Server 2012 operating system, Windows Server 2012 R2 operating system, and Windows Server 2016 Technical Preview operating system: If this flag is present, the client can only view objects and attributes that are otherwise accessible to the client. If this flag is not present, the server checks if the client has access rights to read the changes in the NC.

This means the identity requesting the use of the DirSync control does not require any permission or right if this flag is set. The caveat being that the application will only receive back the objects and attributes that is authorized to view in the directory.

In the MSDN article noted here, you will notice that the explanation of that flag looks to have been cut off or mistakenly forgotten. Looks like someone made a boo boo. Searching for the flag does yield this article which contains the proper explanation of the flag.

Another thing to note is that DirSync requests to a domain controller are not logged in any event log that I could find. Additionally, they are not logged as traditional LDAP queries are when Field Engineering is enabled. This makes a network capture your only way to identify an application using the DirSync control, unless the application is encrypting the tunnel with TLS. In that scenario you are out of luck. There are rumors that this information will be provided in 2016, but I have yet to test it.

Well there you go, the connector for AD DS uses the DirSync control executed via LDAP to perform its synchronizations against AD DS.

In the next post I will cover the SQL instance that is created during an express installation of Azure AD Connect.

Experimenting with Azure B2C – Sign-in Policies

Posted on by

Hi everyone,

Today we continue to explore the Azure B2C feature set and spend time on sign-in policies. Up to this point we have been using PowerShell to emulate a native client application. Unfortunately B2C is still in public preview and Microsoft hasn’t implemented support for sign-in, edit profile, and password reset profiles for native apps. To work around this, we need to be a bit creative.

To continue testing out these features we’re going to use PowerShell to construct our URI. We’ll then start up Fiddler, enter the URI into Internet Explorer, and observe the behavior from there. Before we begin, ensure you’ve setup your application according to the instructions from my first B2C post.

We need to do a bit more setup now that we’re going to emulate a web application. Run through the following steps.

  1. Configure the application to support Web App / Web API
    Navigate to the Azure Management Portal and log in. Change your directory instance to the B2C directory you created by right clicking the person icon in the top right hand corner. Search for the B2C blade and hit the settings button. Navigate to the applications blade, select your application, and ensure that the Web App / Web API option is set to yes. Register a redirect URI of https://powershell. Refer to the image below.

    webapp.png

  2. Create a Sign-In Policy
    Next up we’ll create a sign-in policy. From within the settings section of the B2C blade, select the Sign-In policy blade and hit the Add button. Configure the following settings:

    1. Name: B2C_1_Signin
    2. Identity Providers: LinkedIn, Local Account Signin
    3. Application Claims: Select all claims
    4. Multifactor authentication: Off
    5. Page UI Customization: Default

    Save the policy.

Now that we’ve configured our application with a web app redirect URI and added our sign-in policy we can begin testing. Download the PowerShell script linked below. We will use this script to generate our authorization request.

B2C Signin Demo

Once you have downloaded the ZIP, pull out the PowerShell script and fill in the appropriate fields with your tenant’s information. Run the script and copy the resulting URI.

Open Fiddler and ensure it is set to capture HTTPS traffic. You can double-check by going to to the Tools drop down menu, selecting Fiddler Options, navigating to the HTTPS tab and ensuring that both the Capture HTTPS CONNECTs and Decrypt HTTPS traffic are checked. Check out the screenshot below.

Fiddler-Settings.png

Now that Fiddler is capturing, open up your browser of choice and place the URI you generated from the script into the address bar. You browser will be redirected to Microsoft where you will need to choose your identity provider. For this example we will be choosing LinkedIn. You will be prompted to authenticate and give the application permissions to access your LinkedIn information.

After you have authenticated to LinkedIn your browser will be redirected to Microsoft to pickup the identity token and authorization code, then redirected once again to the redirect URI we configured in our earlier steps. The redirect will timeout and fail, but we don’t need to be concerned about that. Stop Fiddler from capturing and let’s examine the results. You’ll want to select the last captured session as seen in the screenshot below.

FiddlerCapture.png

If we examine the XML in the page we received back from Microsoft, we see we received back both an id token and a code. Let’s tackle the code first. The code you receive back can be exchanged for a bearer access token from Microsoft. Right now that access token has limited purpose in that it can only be used within your application. You can’t use that token to access other resources like the Graph endpoint for the B2C directory. MS plans on adding more functionality to that token in the future.

Back to the id token. Copy the id token line from Fiddler, remove the XML, and paste the remained into a JWT decoder. I’m partial to Calebb. The result is something similar to the screenshot below.

idtoken.png

Here we see again our IdP is LinkedIn and we receive some information from our LinkedIn profile including the job title and email address. Notice how we also received the values for the claims we had the user setup during sign-up. We could then take these claims and use them to customize the user’s experience to our application. Also notice the user’s OID, which we could be used to query for information about the user in the B2C Azure AD instance.

As you have seen through this example, the possibilities with B2C are many while the code to interact with it is simple enough for a non-developer to grasp and interact with. B2C represents an excellent way to demonstrate the power of modern identity standards and protocols like OAuth 2.0 and Open ID Connect 1.0 to your developer community.

In the next post we’ll play with both the edit profile and password reset portal. See you then!