Category Archives: Azure AD

Azure AD allows duplicate group names

28/06/2016 Morgan Simonsen Leave a comment

You would expect that a service that is responsible for the naming of objects within a namespace should prohibit the creation of objects with the same leaf name and fully qualified name. Put simply you should not be able to have two files in the same directory with the exact same name in your file system. Likewise a directory service should do the same, or should it…?

It depends on the rules of the service actually, and what those rules specify must be unique. Take good old Windows Server Active Directory for example. Active Directory is based on LDAP and in the LDAP naming scheme an object may have the same Relative Distinguished Name (RDN), as long as the Distinguished Name (DN) is unique. In this case the RDN is the leaf name and the DN is the fully qualified name. So you can have two users named John Doe as long as they do not both reside within the same Organizational Unit (OU), or location, in the directory. So in AD the rules specify that the DN must be unique. There are also other rules like the ones that say no two users can have the same sAMAccountName or UserPrincipalName properties.

Azure Active Directory also has similar rules, for example you can’t create two AAD users with the same UPN (but they can have the same name). Azure AD groups act differently however. First of all they don’t have UPNs, they only have names (DisplayName attribute). So for groups the rules say that it is the ObjectID property of the group that must be unique, not the name. You can test this yourself easily with PowerShell. Run this command against your AAD tenant twice or more:

New-MsolGroup -DisplayName "GroupWithTheSameName"

It will succeed and you are left with a number of groups which look identical until you look at their ObjectID properties. I’m sure you can imagine the interesting side-effects of having more than one group with the same name… How is this allowed you ask?

The answer is hybrid identity. Azure AD and it’s local sync component; Azure AD Connect, supports syncing users and groups from multi-domain forests and multiple disparate forests into the same Azure AD tenant. This is great for consolidation scenarios, but to understand exactly how it relates to duplicate group names in Azure AD; let’s look at the rules for uniqueness in Active Directory again:

Single forest
- Users must have a unique UPN attribute within a forest, and a unique sAMAccountName attribute within the domain. No such requirement exists between forests. The RND can be the same as long as the DN is unique.
- Groups must have unique sAMAccountName attributes within a domain. No such requirement exists between forests. The RND can be the same as long as the DN is unique.

The mechanism within a forest that makes sure the above requirements are met is the global catalog (GC).

Multi forest
- Anything goes, nothing is shared between forests, even forests that trust each other. You could even have two forests with the same forest root name and UPN suffixes. There would not be able to interact with each other of course.

Form this we see that we can have groups that have the same name, they are only separated by their sAMAccountName attributes in Active Directory. Azure AD Connect does not synchronize the sAMAccountName into Azure AD so we get duplicate groups.

At this point you may be wondering what happens if you have two disparate forests with the same forest root name, how will they sync? Answer is they won’t, that is not a supported scenario by Azure AD Connect, which uses DNS to find the DCs of the forests.

You may also be wondering why this does not apply to users. Users have a unique attribute that is synced into Azure AD; the UPN. As long as it is unique within the forest the user will sync to Azure AD. If you have two forests with the same UPN for two or more users, but still are able to be part of the same Azure AD Connect sync installation, something which is possible if you configure the same UPN suffix in both forests, Azure AD connect will block the syncing when it encounters these users.

NOTE: Manipulating Active Directory directly it is actually possible to have two users with the same UPN in the same domain or forest. If you try to sync those users into Azure AD they will be blocked like described above.

The good news regarding groups is that Microsoft are working on a way to handle groups better in Azure AD Connect so that we do not get these duplicates.

Always fun with a little directory service internals 🙂

Active Directory, Azure AD, Microsoft Azure

How to configure SAML SSO with the Cisco Meraki Dashboard and Azure Active Directory

27/05/2016 Morgan Simonsen Leave a comment

Introduction

The fine people at Cisco Meraki have recently enabled SAML SSO support to their Meraki Dashboard service. For those of you who don’t know Meraki is Cisco’s cloud managed networking solution. Basically you manage all your networking equipment from a web portal. For more information about Meraki, go here.

Whenever I start using a new web application, which is what the Meraki Dashboard is, I always look for options to integrate it with my existing identity platform, which in my case is Azure AD. The benefits of doing this should be apparent and are not in the scope of this post, but basically I want to control access to all applications with one identity and thus limit the numbers of logons I have to maintain.

Note: Let me just mention that at the time of writing; the SAML SSO feature of the Meraki Dashboard is in Beta.

So let’s look at how we can now integrate Azure AD and Meraki.

Setup

Meraki have provided their own documentation on how to set up SAML SSO with either ADFS or OneLogin, this documentation is available here. But we want to use Azure AD.

Configure SSO

In this section we complete the basic SSO setup.

First enable SAML SSO for your organization. Just enable it for now and press Save.
Go to the Azure portal and add a new application to your Azure AD tenant. Select to add an application from the gallery and then select Custom. Name your application something like Meraki Dashboard:
On the page of your newly created application select Configure single sign-on.
Select Microsoft Azure AD Single Sign-On as the sign on method.
For your application identifier and reply URL enter https://dashboard.meraki.com.

NOTE: We will change the value of the Reply URL in the following steps.
Download the certificate in Base 64 format and open it.
On the Details tab, find the certificate thumbprint and copy it.
Go back to the Meraki Dashboard and paste the thumbprint value into the X.509 cert SHA1 fingerprint field. You must replace all spaces with colons. Hit Save. You should now have a Consume URL displayed, it will look something like this:
https://n150.meraki.com/saml/login/<unique ID>. Copy this value, we need it later. Enter the URL of the Azure AD MyApps portal in the SLO logout URL field. Your complete configuration should now look something like this:

The logout URL is where the Meraki Dashboard will redirect users when they sign out, this location should be where they can sign in again, which in this case is the MyApps portal.
Go back to the Azure AD portal and go back one step in the Configure Single Sign-On wizard to enter this value into the Reply URL box. Reply URL is also known as Assertion Consumer Service (ACS) and is where the application expects the authentication response from the IdP. Your final settings should look like this:
Advance to the page of the wizard where you downloaded the certificate and check the box labelled Confirm that you have configured single sign-on as described above. Checking this will enable the current certificate to start working for this application.
Finish the Configure Single Sign-On wizard.

Configure SAML Roles in your Meraki organization

Now we need to configure roles in Meraki Dashboard to control the level of access that SSO users get. You can configure many roles and granular network access here, but we will create only one role.

Go to the Meraki Dashboard and navigate tot Organization\Administrators.
Find the SAML administrator roles section and select Add SAML role
Name the new role Organization and set organization access to full, do not select any target networks:

Configure Claims

In this section we configure the claims that the Meraki Dashboard needs to work. Currently Meraki Dashboard requires a username and a role claim, issued using their naming standard.

In the Azure AD portal, go to the Attributes tab of the Meraki Dashboard application.
Add the following attributes:

Attribute name: https://dashboard.meraki.com/saml/attributes/username

Attribute value: user.userprincipalname

Type: User attribute

Attribute name: https://dashboard.meraki.com/saml/attributes/role

Attribute value: Organization

Type: Constant

Feel free to delete any claims you don’t want to send to the Meraki Dashboard.

Configure Access to the Meraki Dashboard application

In this scenario we use Azure AD as the control plane for who gets the Organization role we specified earlier. We do this by assigning the Meraki Dashboard application to the specific users we want to be organization admins.

In the Azure AD portal select the Users and Access tab of the Meraki Dashboard application
Select Show: All Users in the drop down box.
Select the users you want to be organization admins and hit Assign at the bottom of the page.

About Roles in this setup

As you can see from the above configuration, all users that are assigned the Meraki Dashboard application will get full Organization access, based on the role we created This is almost certainly not what you want, but this is just an example. In the Meraki guide for ADFS we see that they use Active Directory groups to select which role is passed in the claim. Unfortunately, the logic to do this is not available in Azure AD at the moment. You cannot select a claim value based on a group. What you can do instead is use a free attribute in either your local Active Directory or Azure AD to specify the name of the Meraki role to give the user. To accomplish this you must first map out all the Meraki roles you need and then provide the names of these roles in the role claim, based on the value of the attribute.

Testing access

Now let’s see if it worked.

Log in to the Azure AD MyApps portal as one of the users that you assigned to the Meraki Dashboard application; https://myapps.microsoft.com.
Meraki Dashboard show now show up as an available application:
Hit the icon and you should now be forwarded to the Meraki Dashboard.
Notice that your username at the top is now your User Principal Name from Azure AD.
Navigate to Organization\Administrators and hit SAML login history. This will display all SAML logins to the dashboard. Your login should show up here. You can also press the value in the timestamp and you will see more details, and you can even view the entire XML assertion.

Further customization

Hopefully everything is working for you. If you want to further customize this setup you could for example add a logo to your app and remove the claims not needed by the Dashboard. You now also have access to all the advanced access policies of Azure AD and can add MFA and location based access rules and provide delegated self-service access.

Notes about the setup

There are a few things to note about the Meraki SSO support in general and this setup in particular.

Meraki Dashboard currently only supports Identity Provider (IdP) initiated sign-on. This means you have to start in the Azure MyApps portal, log in, and then proceed to the Meraki Dashboard by pressing the icon. Going to the dashboard first and trying to log in with an ID from Azure AD (or any IdP) will not work. This last scenario is what is known as Service Provider Initiated sign-on (SPinit). (I’m thinking you should be able to create a smart URL here, but have not have time to test that yet.)
If the username of the admin that signs in with SSO is already registered as a regular dashboard admin the sign in will fail.
There is already a pre canned Cisco Meraki Dashboard app in the Azure AD application gallery, but this only supports password SSO, which means that you will have to enter your regular Dashboard account login details into the Azure AD credentials vault and then have Azure AD forward those credentials when users sign in. This is not true SSO. However, I recommend you harvest the icons from this app and use in the one you create. (The URL of the logo is: https://az495088.vo.msecnd.net/app-logo/merakidashboard_215.png)

More information

For more information on Meraki Dashboard permissions and administrator types, refer to the article on managing administrative users

Azure AD, Microsoft Azure

How to find the GUID of your Azure AD tenant

27/10/2015 Morgan Simonsen Leave a comment

All Azure AD tenants are named as sub-domains of the root onmicrosoft.com. For example yourcompany.onmicrosoft.com. Some very early adopters of eg. Office 365 might also have tenant names that look like this emea.microsoftonline.com, but AFAIK all new tenants will inherit the onmicrosoft.com domain. But names are fickle, so every Azure AD tenant also has a Globally Unique IDentifier, or GUID that is guaranteed to be unique (as the name implies) within Azure AD.

When you sign up for a service like Office 365, which uses Azure AD in the same way Exchange Server uses Active Directory. You can immediately start using services like Exchange Online and Skype with your default Azure AD tenant domain. Needless to say, it is not a user friendly domain name, either for logons or receiving email, so almost everyone adds one or more custom domains.

Sometimes it might be useful to know what the GUID of your tenant is. Perhaps you need it to file a support request, or you want to work out what is going on when you do federated sign-ons against Azure AD or you are working with Azure AD B2B.

Finding the GUID is not as easy as you might think. It is not displayed in the Azure AD portal, nor is it available in Azure AD PowerShell. You actually have to dig a little to find it. Sometimes it pops up in your browser address bar when you log in, but you have to be sure that it actually is your GUID that is display there, and not someone else’s.

Here is the easiest way I have found to display the GUID:

Log into the Azure AD Portal (manage.windowsazure.com)
Find or create a custom application that is integrated with your Azure AD tenant. To create a new application is very easy and you can immediately delete it once you have what you want.
Press the View Endpoints button at the bottom of the screen.
In the dialogue that pops up, your GUID is the long sting directly behind login.microsoftonline.com:
Copy your GUID and store it in a safe place.

If I come up with an easier way to find the tenant GUID I will update this post.

Morgan

Azure AD, Microsoft Azure

Azure AD Sync/Connect Events

20/10/2015 Morgan Simonsen Leave a comment

Here is a table of Azure AD Sync/Connect related entries that you will find in the Application log of your sync server. Use this table to quickly create filers and find what you are looking for. This is not a complete list!

Event ID	Level	Source	Text	Description	Family
601	Information	Directory Synchronization	Password Synchronization Manager has started.	Indicates the password sync manager process has started for the specified AD domain.	Password hash synchronization/write-back
605	Information	Directory Synchronization	The following password changes failed to synchronized and have scheduled for retry.	Lists password changes that were note successful.	Password hash synchronization/write-back
609	Information	Directory Synchronization	Password Synchronization service has stopped.		Password hash synchronization/write-back
611	Information	Directory Synchronization	Directory Synchronization full sync is in progress. Password synchronization agent will be paused until directory synchronization full sync is complete.	Password sync is pausing until regular sync completes.	Password hash synchronization/write-back
650	Information	Directory Synchronization	Provision credentials batch start. Count: <#>, TrackingID :	Signifies the start of a credentials (password) sync batch. This event will repeat for each batch.	Password hash synchronization/write-back
651	Information	Directory Synchronization	Provision credentials batch end. Count: 37, TrackingID :	Signifies the end of a credentials (password) sync batch. This event will repeat for each batch.	Password hash synchronization/write-back
653	Information	Directory Synchronization	Provision credentials ping start. TrackingID :		Password hash synchronization/write-back
654	Information	Directory Synchronization	Provision credentials ping end. TrackingID :		Password hash synchronization/write-back
656	Information	Directory Synchronization	Password Change Request - Anchor : , Dn : , Change Date :	The Anchor value will be found in Azure AD as the sourceAnchor attribute, thus connecting an on-premises object with a cloud object. Each event will have up to about 50 entries.	Password hash synchronization/write-back
657	Information	Directory Synchronization	Password Change Result - Anchor : , Dn : , PwdChangeOnLogon=, Result : .	Indicates the result of a particular password change operation against Azure AD. This event will repeat and include up to 50 entries.	Password hash synchronization/write-back
658	Information	Directory Synchronization	Windows credential sync is disabled in the registry		Password hash synchronization/write-back
659	Information	Directory Synchronization	IsForcePasswordChangeOnLogonFeatureEnabled=		Password hash synchronization/write-back
104	Information	Directory Synchronization	Export:: Iteration: <#>, Current batch size: <#>, Exported total: <#>, Successful total: <#>, TrackingId: .	Export	Object import/synchronization/export
105	Information	Directory Synchronization	Import:: Iteration: <#>, Current batch size: <#>, Imported total: <#>, More: , TrackingId: , SyncCookie: .	Import	Object import/synchronization/export
106	Error	Directory Synchronization	Failed to connect to Windows Azure Active Directory during export. Exception: Microsoft.Online.Coexistence.ProvisionException: An unknown error occurred with the Microsoft Online Services Sign-in Assistant. Contact Technical Support. ---> Microsoft.Online.Coexistence.Security.WindowsLiveException: SetCredential() failed. Contact Technical Support. at Microsoft.Online.Coexistence.Security.LiveIdentityManager.OpenIdentity(String federationProviderId, String userName, String password) at Microsoft.Online.Coexistence.ProvisionHelper.GetLiveCompactToken(String userName, String userPassword) --- End of inner exception stack trace --- at Microsoft.Online.Coexistence.ProvisionHelper.WindowsLiveExceptionHandler(WindowsLiveException ex) at Microsoft.Online.Coexistence.ProvisionHelper.GetLiveCompactToken(String userName, String userPassword) at Microsoft.Azure.ActiveDirectory.Connector.ProvisioningServiceAdapter.Initialize() at Microsoft.Azure.ActiveDirectory.Connector.DirSyncConfigurationAdapter.GetCurrentCloudDirSyncConfiguration() at Microsoft.Azure.ActiveDirectory.Connector.Connector.OpenExportConnection(KeyedCollection`2 configParameters, Schema schema, OpenExportConnectionRunStep openExportConnectionRunStep).		Object import/synchronization/export
109	Error	Directory Synchronization	Failure while importing entries from Windows Azure Active Directory. Exception: Microsoft.Online.Coexistence.ProvisionException: An unknown error occurred with the Microsoft Online Services Sign-in Assistant. Contact Technical Support. ---> Microsoft.Online.Coexistence.Security.WindowsLiveException: SetCredential() failed. Contact Technical Support. at Microsoft.Online.Coexistence.Security.LiveIdentityManager.OpenIdentity(String federationProviderId, String userName, String password) at Microsoft.Online.Coexistence.ProvisionHelper.GetLiveCompactToken(String userName, String userPassword) --- End of inner exception stack trace --- at Microsoft.Azure.ActiveDirectory.Connector.GetImportEntriesTask.GetNextBatch() at Microsoft.Azure.ActiveDirectory.Connector.Connector.GetImportEntriesCore() at Microsoft.Azure.ActiveDirectory.Connector.Connector.GetImportEntries(GetImportEntriesRunStep getImportEntriesRunStep).		Object import/synchronization/export
114	Information	Directory Synchronization	Export cycle completed. Tracking id:	Export. This event will repeat for each cycle.	Object import/synchronization/export
115	Information	Directory Synchronization	ProvisioningServiceAdapter::ExecuteWithRetry: Action: ProvisionCredentials, Attempt: 0, Exception: Microsoft.Online.Coexistence.ProvisionRetryException: An error occurred. Error Code: 51. Error Description: Access to Azure Active Directory has been denied. Contact Technical Support. Tracking ID: bd0defbf-77ce-4ee6-afe6-6ec73537325e Server Name: . at Microsoft.Online.Coexistence.ProvisionHelper.AdminWebServiceFaultHandler(FaultException`1 adminwebFault) at Microsoft.Online.Coexistence.ProvisionHelper.InvokeAwsAPI[T](Func`1 awsOperation, String opsLabel) at Microsoft.Azure.ActiveDirectory.Connector.ProvisioningServiceAdapter.<>c__DisplayClassb.b__a() at Microsoft.Azure.ActiveDirectory.Connector.ProvisioningServiceAdapter.ExecuteWithRetry(String actionName, Action action).		Object import/synchronization/export
116	Information	Directory Synchronization	Calling UpdateDirSyncConfiguration with: [CloudDirSyncConfiguration [PreventAccidentalDeletion DeletionPrevention=EnabledForCount, ThresholdCount=500, ThresholdPercentage=0], [CurrentExport DirSyncObjectAdds=0, DirSyncObjectDeletes=0, DirSyncObjectUpdates=0, DirSyncClientMachineName=, TotalConnectorSpaceObjects=2722], [Writeback UnifiedGroupContainer=, UserContainer=]]		Object import/synchronization/export
116	Information	Directory Synchronization	Getting the current DirSyncConfiguration.		Object import/synchronization/export
116	Information	Directory Synchronization	Returned configuration: [CloudDirSyncConfiguration [PreventAccidentalDeletion DeletionPrevention=EnabledForCount, ThresholdCount=500, ThresholdPercentage=0], [CurrentExport DirSyncObjectAdds=0, DirSyncObjectDeletes=0, DirSyncObjectUpdates=9, DirSyncClientMachineName=, TotalConnectorSpaceObjects=2722], [Writeback UnifiedGroupContainer=, UserContainer=]]		Object import/synchronization/export
117	Information	Directory Synchronization	Import prefetch:: Start - , End , Idle 00:00:00		Object import/synchronization/export
904	Information	DirectorySyncClientCmd	Import/Sync/Export cycle completed (Initial). Starting: Device Certificate Sync Step... Finished: Device Certificate Sync Step. Duration: 0.045 sec. Finished: Purging Run History. Duration: 0.144 sec. Finished: Running the AAD Password Reset Feature. Duration: 0.746 sec. Starting: Purging Run History... Finished: Device Certificate Sync Step. Duration: 0.043 sec. Starting: Initializing the program configuration... Starting: Device Certificate Sync Step... Starting: Purging Run History... Finished: Purging Run History. Duration: 0.72 sec. Starting: Getting the AAD Connector Name... Finished: Getting the AAD Connector Name. Duration: 0.679 sec. Finished: Getting the AD Connector Names. Duration: 0.879 sec. Finished: Initializing the program configuration. Duration: 0.039 sec. Starting: Getting the AD Connector Names... Exporting to all Sources Finished Exporting to Target Synchronizing from all Sources Synchronizing from Target AAD password reset is not currently configured. Finished: Running the AAD Password Reset Feature. Duration: 9.605 sec. Starting: Running the AAD Password Reset Feature... Import/Sync/Export cycle completed (Delta). Finished: Executing the run profiles. Duration: 104.649 sec. Exporting to all Sources Synchronizing from all Sources Synchronizing from Target Importing Import/Sync/Export cycle started (Delta). Initializing Import/Sync/Export cycle completed (Delta). Finished: Executing the run profiles. Duration: 18.283 sec.	Events from the DirectorySyncClientCmd.exe tool used by Task Scheduler and Azure AD Connect setup to run sync.	Object import/synchronization/export
904	Information	MicrosoftAzureActiveDirectoryClient	Starting: Setting up the ...... Finished: Running SyncScheduler task.. Duration: 0.131 sec. Starting: Enabling SyncScheduler task.... Finished: Running SyncScheduler task.. Duration: 2.573 sec. Starting: Running SyncScheduler task.... Finished: Enabling SyncScheduler task.. Duration: 2.17 sec. Starting: Setting up the ...... Finished: Setting up the .... Duration: 0.789 sec.
904	Information	AzureActiveDirectorySyncEngine		Each event displays one of the install/setup/uninstall steps of Azure AD Connect setup.	Setup
905	Warning	DirectorySyncClientCmd	Attempting to obtain Azure AD Sync Scheduler mutex
905	Warning	AzureActiveDirectorySyncEngine	RemoveSqlLocalDbInstance: Error while removing database ADSync. This may be expected. Details: Microsoft.Azure.ActiveDirectory.Synchronization.Framework.ProcessExecutionFailedException: Exception: Execution failed with errorCode: 1. Details: Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : SQL Server Network Interfaces: The specified LocalDB instance does not exist. [x89C50107]. . Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : Login timeout expired. Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online.. at Microsoft.Azure.ActiveDirectory.Synchronization.Framework.ProcessAdapter.StartProcessCore(String fileName, String arguments, String workingDirectory, NetworkCredential credential, Boolean loadUserProfile, Boolean hideWindow, Boolean waitForExit) at Microsoft.Azure.ActiveDirectory.Synchronization.Framework.ProcessAdapter.StartBackgroundProcessAndWaitForExit(String fileName, String arguments, String workingDirectory, NetworkCredential credential, Boolean loadUserProfile) at Microsoft.Azure.ActiveDirectory.Synchronization.Framework.SqlCmdAdapter.ExecuteCommand(String arguments, NetworkCredential credential) at Microsoft.Azure.ActiveDirectory.Synchronization.Setup.SynchronizationServiceSetupTask.<>c__DisplayClass1d.b__1c()
906	Error	DirectorySyncClientCmd	DirectorySyncClientCmd: invalid command line argument: (INTIAL)
2001	Information	ADSync	The service was started successfully.		Service
2002	Information	ADSync	The service was stopped successfully.		Service
6012	Warning	ADSync	The management agent failed on run profile "Full Import" because the management agent did not import any objects during the run step.
6100	Warning	ADSync	The management agent step execution completed on run profile "Full Synchronization" with errors. Additional Information Discovery Errors : "0" Synchronization Errors : "0" Metaverse Retry Errors : "458" Export Errors : "0" Warnings : "0" User Action View the management agent run history for details.
6105	Warning	ADSync	The management agent step execution completed on run profile "Full Import" but some objects had exported changes that were not confirmed on import. Additional Information Discovery Errors : "0" Synchronization Errors : "0" Metaverse Retry Errors : "0" Export Errors : "0" Warnings : "5" User Action View the management agent run history for details.
6110	Warning	ADSync	The management agent step execution completed on run profile "Full Import" but the watermark was not saved. Additional Information Discovery Errors : "0" Synchronization Errors : "0" Metaverse Retry Errors : "0" Export Errors : "0" Warnings : "0" User Action View the management agent run history for details.
6126	Warning	ADSync	The management agent completed run profile "Delta Import" with a delta import or delta synchronization step type. The rules configuration has changed since the last full import or full synchronization. User Action To ensure the updated rules are applied to all objects, a run with step type of full import and full synchronization should be completed.
6127	Warning	ADSync	The management agent completed run profile with a delta import or delta synchronization step type. The rules configuration has changed since the last full synchronization. User Action To ensure the updated rules are applied to all objects, a run with step type of full synchronization should be completed.
6201	Information	ADSync	The server encryption keys have been successfully created. User Action Store a backup of the encryption keys in a secure location. This will be required for server restore operations.
6801	Error	ADSync	The extensible extension returned an unsupported error. The stack trace is: "Microsoft.Online.Coexistence.ProvisionException: An unknown error occurred with the Microsoft Online Services Sign-in Assistant. Contact Technical Support. ---> Microsoft.Online.Coexistence.Security.WindowsLiveException: SetCredential() failed. Contact Technical Support. at Microsoft.Online.Coexistence.Security.LiveIdentityManager.OpenIdentity(String federationProviderId, String userName, String password) at Microsoft.Online.Coexistence.ProvisionHelper.GetLiveCompactToken(String userName, String userPassword) --- End of inner exception stack trace --- at Microsoft.Azure.ActiveDirectory.Connector.GetImportEntriesTask.GetNextBatch() at Microsoft.Azure.ActiveDirectory.Connector.Connector.GetImportEntriesCore() at Microsoft.Azure.ActiveDirectory.Connector.Connector.GetImportEntries(GetImportEntriesRunStep getImportEntriesRunStep) Azure AD Sync 1.0.8667.0"
6803	Error	ADSync	The management agent failed on run profile "Export" because the server encountered errors.
6941	Error	ADSync	ECMA2 MA export run caused an error. Error Name: Error Detail: Tracking Id:	DataValidationFailed InvalidSoftMatch AttributeValueMustBeUnique IdentityDataValidationFailed
6943	Information	ADSync	Password sync started for management agent .
0	Error	Directory Synchronization	An unknown error occurred with the Microsoft Online Services Sign-in Assistant. Contact Technical Support. SetCredential() failed. Contact Technical Support. (0x8009000B)

Azure AD, Microsoft Azure

New preview version of Azure AD PowerShell available (Yes, it now supports ADAL!)

24/09/2015 Morgan Simonsen 1 Comment

I guess the title says it all!

Here is the link to the Microsoft Connect site to download:

http://connect.microsoft.com/site1164/

Connect-MSOLService now brings up the familiar ADAL prompt with MFA and ADFS support etc. Make sure to read the release notes included, and you should probably uninstall the Microsoft Online Sign In assistant.

Here are the changes:

Dependency on the Microsoft Online Service sign in assistant removed.
Name of module updated Windows Azure -> Microsoft Azure
Connect-MsolService parameter -CurrentCredentials removed.
Connect-MsolService parameter -AccessToken added to enable AAD Connect, and other callers to use the PowerShell as a client library.
New device management cmdlets:
- Get-MsolDevice
- Enable-MsolDevice
- Disable-MsolDevice
- Remove-MsolDevice

Few apparent changes in the list of installed products though:

Before:

After:

Morgan

Azure AD, Microsoft Azure

Manage Azure Active Directory without an Azure subscription (sort of)

11/11/2014 Morgan Simonsen 1 Comment

Introduction to Azure Active Directory

Azure Active Directory is Microsoft’s cloud identity platform and the identity provider for all the services in the Microsoft Cloud ecosystem. It is a multi tenant global identity platform, available in all the Azure regions. If you have Office 365, Windows Intune or Microsoft Azure; you also have Azure Active Directory. To call it Azure Active Directory can sometimes be a little misleading because although it is part of the Azure platform, it exists outside the other services we generally associate with Azure, like Infrastructure-as-a-Service or Platform-as-a-Service. Even though Azure Active Directory shares its name with the Windows Server Active Directory Domain Services role we find in Windows Server, Azure AD offers a lot more than its earthbound namesake. Azure AD is not just a directory that stores information about users and groups, and authenticates them, it also has identity lifecycle management, advanced reporting, multi-factor authentication and support for OAuth, OpenID Connect and WS-* protocols. The complete feature set is too long to list here, and outside the scope of this post anyway. Azure AD is backed by a REST API called the Graph API.

Azure AD comes in three flavors; Free, Basic and Premium. The base offering, Free, can be used by anyone for almost anything. You could build your own webapp in AWS and use Azure AD as the identity provider for example. Like I mentioned, if you already have Office 365, you also have Azure AD. The Office 365 portal offers one view into Azure AD via the admin portal (portal.office.com).

Another way to interact with Azure AD is via PowerShell. The Azure AD PowerShell module has over 70 cmdlets:

As you can see from the list above, it is Azure AD that handles federation and directory integration with your existing on-premises directories, not Office 365.

Management of Azure AD

As we’ve seen there are several views into Azure AD; PowerShell, Office 365 or Windows Intune portals. But to manage the full set of available features in Azure AD we need to use the Azure Management Portal (manage.windowsazure.com).

If you have an Azure subscription you either got an Azure AD tenant when you signed up, you created one in the Azure portal afterwards or you associated your existing Azure AD tenant with your Azure subscription. Either way that tenant then becomes visible in the Azure portal like in the screenshot above. From here you can manage all the base functionality of Azure AD like directory integration, domain verification, multi-factor authentication, reporting etc. You can also add users form other Azure AD tenants (provided you have access to the tenant in question) and add Microsoft Accounts (MSA).

Azure AD vs. Azure

There are several ways to get Azure AD without having an Azure subscription. Maybe you signed up for an Office 365 or Windows Intune trial, or something else. However you got an Azure AD tenant you now want to manage it from the Azure portal. But you cannot do that without a subscription. If you try to log on to the Azure Management portal with a Global Administrator from your Azure AD tenant you get an error telling you you do not have any active Azure subscriptions:

What you are experiencing here is the dichotomy between Azure and Azure AD. Azure AD is a separate service from Azure with its own roles and permissions. A user account in Azure AD can have one of several roles inside the Azure AD tenant, but no roles in Azure. The roles in Azure AD are:

Organization role	Description
User	Regular user without any special privileges or permissions. Can read most information in the directory (tenant).
Password Administrator	Resets passwords, manages service requests, and monitors service health. Password administrators can reset passwords only for users and other password administrators.
User Administrator	Resets passwords, monitors service health, and manages user accounts, user groups, and service requests. Some limitations apply to the permissions of a user management administrator. For example, they cannot delete a global administrator or create other administrators. Also, they cannot reset passwords for billing, global, and service administrators.
Service Administrator	Manages service requests and monitors service health.
Billing Administrator	Makes purchases, manages subscriptions, manages support tickets, and monitors service health.
Global Administrator	Has access to all administrative features. The person who signs up for the Azure AD tenant becomes the first global administrator. Only global administrators can assign other administrator roles. There can be more than one global administrator at your company.

More information about the Azure AD administrative roles is available here. These roles can be granted to either Microsoft Accounts or Azure AD accounts.

As mentioned Azure has its own permissions and roles. The only two roles at present is the Service Administrator and one or more Co-Administrators. The users assigned these roles can be either Microsoft Accounts or Azure AD accounts. The Azure Preview portal (portal.azure.com) has support for Role Based Access Control (RBAC) which gives more granular control of resources. The users assigned roles in RBAC are also either Microsoft Accounts or Azure AD accounts.

So now we know that you can have two sets of permissions and roles; one for Azure AD and one for Azure. We have also established that to fully manage your Azure AD tenant you need access to the Azure Management Portal, but for that you also need an Azure subscription. You could create a an Azure trial subscription with your Azure AD Global Administrator account, but that might be more than you bargained for and requires registering a credit card and managing that subscription. Or you could add the Azure AD Global Administrator to an existing Azure subscription you have, but that will require you to use an MSA to do the linking and the account must be added as a co-admin, thus granting full access to your entire Azure subscription. This is not a good security practice. You could also manage Azure AD directly with PowerShell, but this would not give you full access to all features.

The optimal solution to this would be to let Azure AD Global Administrators log on to the Azure Management portal without a subscription to manage just Azure AD, or to have a separate portal for just Azure AD, but that is not possible. There is however an option that comes pretty close.

Azure AD only Azure subscriptions

With a special Azure offer code we can sign up for a subscription that does not require a credit card, is not a trial subscription, and that only gives access to Azure AD. Here’s how to do that:

Make sure you use a clean browser or browser tab where you are not already signed in to any Microsoft services, either Azure AD based or MSA based.
Use the following URL:
https://account.windowsazure.com/signup?offer=MS-AZR-0110P
Select Sign in with your organizational account and sign in with the Global Administrator account of your Azure AD tenant.
Complete the Azure sign up form, note that the only thing you need to do is verify your mobile phone number.
Hit Sign up and you will be forwarded to the Azure Account portal while your subscription is set up.
Hit Portal to be forwarded to the management portal:

You now have access to manage the full feature set of Azure AD in the management portal without having to sign up for a trial or pay as you go subscription. This subscription has the following characteristics:

It is a regular Azure subscription
It has a subscription ID that can be managed and associated with EA
It will not expire or incur charges
It can only manage Azure AD services
You can assign licenses for Azure AD Basic or Free since these are purchased over licensing agreements as opposed to Azure consumption
You cannot create any other Azure resources except those related to Azure AD; these are Directory, ACS and MFA
You can add other co-admins and change the service admin from the account portal
The account that signed up for this subscription is also the account admin and has access to the account portal

Further steps

Now that you have access to the full management experience through the Azure portal you can add other Azure AD tenants that you want to manage. The only way to accomplish this is to use a Microsoft Account (MSA). The MSA directory (formerly Live ID) is the only directory from which everyone can read user objects, both other MSAs and Azure AD users. This makes it possible to “bridge” two Azure AD tenants and make one MSA, or Azure AD account, a Global Administrator of both tenants. You still need to create a the special type of Azure subscription described in this post though. Here are the overall steps:

Create an Azure AD only subscription for the first Azure AD tenant following the steps in the previous section.
Select or create a suitable Microsoft Account
Make the MSA a co-admin in your Azure subscription
Make the MSA a Global Admin in your Azure AD tenant
Make the MSA a Global Admin of the other Azure AD tenant you want to manage in your Azure subscription. This can be done either by creating another Azure AD only subscription or in the full Azure portal if the Azure AD tenant in question is associated with an existing subscription. Ask an admin for help if needed.
You now have one MSA that is both a Global Admin in your Azure AD only Azure subscription, a co-admin on your Azure AD only subscription and a Global Admin in another Azure AD tenant you want to add and manage from your Azure AD only subscription.
Log in to the Azure AD portal with the MSA
Both directories should now be visible
Since the MSA can read from both Azure AD tenants you can now add Azure AD accounts from one to the other.
Create a user in the second Azure AD tenant that is sourced from the first Azure AD tenant by selecting New User and then User in another Windows Azure AD directory.
Make the new user a Global Administrator of the directory.
If you wish you can now remove the MSA from both directories and the Azure subscription and only use Azure AD accounts.

Azure AD, Microsoft Azure

Quick and dirty DirSync install automation

29/08/2014 Morgan Simonsen 1 Comment

Here are the steps required to do an automated vanilla install of the latest DirSync tool:

Download the DirSync bits using BITS (the URL always points to the latest version):
Start-BitsTransfer -Source http://go.microsoft.com/fwlink/?LinkID=278924 -Destination c:Tempdirsync.exe

Install the required .NET 3.5 bits:
Add-WindowsFeature -Name NET-Framework-Core

Install DirSync unattended:
.DirSync.exe /quiet

UPDATE: Regarding AADSync

Unfortunately this does not seem to work with the AADSync download.

Azure AD, Microsoft Azure

New PowerShell module for Windows Azure Active Directory

17/04/2013 Morgan Simonsen Leave a comment

A new version of the PowerShell module for Windows Azure Active Directory is available. This module was previously know as the Microsoft Online PowerShell module. The cmdlets all have the word MSOL in them, and the modules are called MSOnline and MSOnlineExtended. The version is still 1.0.0 as were the previous module. New in this release is support for Windows Server 2012; you can install the module on Windows Server 2012 and also configure the version of ADFS in Windows Server 2012. The documentation has also been updated.

32-bit http://g.microsoftonline.com/0BX10en/230
64-bit http://g.microsoftonline.com/0BX10en/423
Documentation http://technet.microsoft.com/en-us/library/hh967628.aspx

Active Directory, ADFS, Azure AD, Microsoft Azure

Norwegian content: How to integrate your on-premise Active Directory with Windows Azure Active Directory

10/04/2013 Morgan Simonsen Leave a comment

I have published a 5 part blog series on the Norwegian Microsoft TechNet Blog, with step by step instructions for setting up integration between your on-premise Window Server Active Directory Directory Service and Windows Azure Active Directory. It covers concepts, single-sign on with ADFS, Directory Synchronization with the DirSync Tool and troubleshooting. So if you speak my native language; head on over:

Morgan

Morgan Simonsen's Blog

Category Archives: Azure AD

Azure AD allows duplicate group names

How to configure SAML SSO with the Cisco Meraki Dashboard and Azure Active Directory

Introduction

Setup

Configure SSO

Configure SAML Roles in your Meraki organization

Configure Claims

Configure Access to the Meraki Dashboard application

About Roles in this setup

Testing access

Further customization

Notes about the setup

More information

How to find the GUID of your Azure AD tenant

Azure AD Sync/Connect Events

New preview version of Azure AD PowerShell available (Yes, it now supports ADAL!)

Manage Azure Active Directory without an Azure subscription (sort of)

Introduction to Azure Active Directory

Management of Azure AD

Azure AD vs. Azure

Azure AD only Azure subscriptions

Further steps

Quick and dirty DirSync install automation

New PowerShell module for Windows Azure Active Directory

Norwegian content: How to integrate your on-premise Active Directory with Windows Azure Active Directory

Information wants to be free!