Category Archives: Microsoft Azure

Cloud, Microsoft Azure, Windows

Packer for Azure Peculiarities

1 Comment

Building images on Azure with Packer I have discovered some things that might be useful to others:

Cannot locate resource group means something else

Error when doing Azure Managed Disk builds:

Build ‘azure-arm’ errored: Cannot locate the managed image resource group <your RG>

What Packer really means is that your credentials are wrong. Check your values for client_id and client_secret. Remember that it is the Application ID that is your client_id, not the name or the object ID.

“full access to this subscription” is not really necessary

The Packers docs state:

“The service principal specified in client_id must have full access to this subscription, unless build_resource_group_name option is specified in which case it needs to have owner access to the existing resource group specified in build_resource_group_name parameter.”

First of all; “full access” is not the name of a role in Azure IAM. Since they go on to mention “owner”, which is a role, later on when discussing the use of a pre-existing resource group, I assume that owner is what they mean. But the Packer service principal does not need owner. It just needs permissions to perform the creation and deletion of resources at the right level. Contributor works fine.

Remember thy OS

Packer commands must use double quotes on Windows and single quotes on Linux. Simple, right? Yet so hard to remember.  AFAICT this is mentioned only once in the Packer docs, in the Intro section, but not in the Template User Variables section. Even the help output of packer.exe (1.2.) on Windows is wrong:

 -var 'key=value' Variable for templates, can be used multiple times.

Will work on Linux, but not on Windows:

$ packer build \
 -var 'aws_access_key=YOUR ACCESS KEY' \
 -var 'aws_secret_key=YOUR SECRET KEY' \
 example.json

Will work on Windows, but not on Linux:

PS> packer build \
 -var "aws_access_key=YOUR ACCESS KEY" \
 -var "aws_secret_key=YOUR SECRET KEY" \
 example.json

Windows images require client_id and object_id

The object_id configuration option is not listed under the required section of the Azure builder, but if you are building a Windows image it is in fact required. This is explained in the object_id explanation, but should be made more clear. After all, if object_id is missing; Packer will not tell you that. Rather it will give you this:

==> azure-arm: ERROR: -> BadRequest : An invalid value was provided for ‘accessPolicies’.

object_id takes as its value the actual object id of the service principal that Packer is using. So client_id needs the application id and object_id needs the object id. What seems strange to me here is that Packer already knows the application id of its service principal and could easily get the object id from that by querying the graph. This is turn could make the whole issue with providing object_id redundant. Packer could just figure it out. This issue is discussed more in this link. If you have the wrong value in object_id you might see this error:

Failed to fetch secret from <KV Name>/packerKeyVaultSecret, HTTP status code=403 (Forbidden)

This is because Packer uses the value provided for object_id in the KeyVault access policy, which is accepted by the Azure ARM API (after all, it is just a GUID), but does not work in the next step when Packer tries to retrieve the value of the secret. Again, the solution is to set the correct value for object_id. People talk more about this issue here.

Happy Packing!

Microsoft Azure

Migrating blog database from ClearDB to Azure DB for MySQL

Leave a comment

Introduction

All of us running our blogs on WordPress have some knowledge of MySQL, which is WordPress’ database back-end. I run my WordPress blog (the one you are reading now) in Azure App Service. We used to be able to create MySQL databases in the Azure portal directly. This was made possible through a partnership between Microsoft and ClearDB. Providing an offering running MySQL in Azure datacenters, but managed by ClearDB. You could see and manage your MySQL resources in the Azure portal, and even pay for your MySQL usage with your Azure credit. This option disappeared some time ago, at which time we all had to start managing our MySQL databases from the ClearDB management portal. At the same time the MySQL resources disappeared from the Azure portal. Since H2 2017 Azure DB has been able to natively support MySQL. This is now a native Azure resource on the same level as regular Azure DB MS SQL. With this new offering I can once again run, manage, and pay for, all my blog resources on Azure. This posts shows how I migrated from ClearDB MySQL to Azure DB for MySQL.

Migration

The steps I followed are available here, and I will not repeat them:

https://azure.microsoft.com/en-us/blog/cleardb-migration-to-azure-database-for-mysql/

There are a few things I did differently.

Database Pricing Tier

I selected the smallest possible database SKU; 1 vCore and 5 GB memory. This seems to be adequate for the traffic my site is receiving.

Database Connection

The Connection strings, under Application settings in the App service did not seem to do anything. After I changed it I started receiving “Error connecting to database” messages in my browser. WordPress stores its database connection settings in wp-config.php, and you need to edit this file. I recommend Kudu. Wp-config.php is in the wwwroot folder. You need to restart your app service after you change it. You will find Kudu under Advanced Tools in your App service. The values you need to change are:

  • DB_USER
  • DB_PASSWORD
  • DB_HOST

Connection Security: Firewall

I recommend to follow the Microsoft blog post author’s setup of allowing only the outbound IP addresses of your Azure App Service in your database firewall rules. You might be tempted to enable the option Allow access to Azure services in the firewall setup, but I recommend against it. This setting allows connections from all Azure public IPs, not just the ones you use. This can potentially open you up to denial of service or other attacks from malicious actors who are also using Azure. If you do decide to use this option, set a good password and monitor your database for connections from IPs you do not use.

Connection Security: SSL

The Microsoft blog post author disables SSL Enforcement on his database, but I wanted to keep that enabled. My WordPress setup did not have the required settings to allow this so I had to add the following to my wp-config.php file:

define( 'MYSQL_CLIENT_FLAGS', MYSQLI_CLIENT_SSL | MYSQLI_CLIENT_SSL_DONT_VERIFY_SERVER_CERT );

This will add the flag to use SSL for database connections and also turn off verification of the database certificate. With this added to my WordPress config I could enable Enforce SSL connection for my database.

I have seen some posts on Server Fault about how using SSL between your front-end and database impacts performance. I have yet to see some detrimental effects of this setting, but will monitor it in the coming days and update this post with my findings, if any.

Azure DB MySQL databases use public certificates signed by DigiCert. More information about SSL support is available here:

https://docs.microsoft.com/en-us/azure/mysql/howto-configure-ssl

This would suggest that I did not need to disable verification of the database server certificate. I want to investigate if I can disable that setting and have certificate validation enabled. More to come on this topic.

There is also a WordPress plugin to handle database SSL connections.

Conclusion

The database migration was very quick. The site seems to be running fine, and I have yet to find any issues. Please sound off in the comments if you experience anything wrong or strange in the coming weeks. I plan not to make any more changes in the immediate future to make sure any issues are related to the database migration and not something else I did. When all is fine I will delete my ClearDB database. Thanks for reading!

/M

Microsoft Azure

Copying Azure Managed disks between regions

Leave a comment

I recently had the need to copy some Azure managed disks to another region. Since managed disks are not backed by storage accounts like unmanaged disks, you cannot simply do a blob copy and be done. You have to copy your managed disk to a temporary storage account in your target region and create a managed disk from it.

I could not find something that did what I wanted, so I had to roll my own in the form of a PowerShell script. The script does the following:

  • Takes a source and target resource group, a target location, a set of managed disks and a target SKU as parameters. (Source and target resource groups can be the same.)
  • Creates a temporary storage account with a random name (mdcopynnnnn) in the target resource group in the target location. A new storage account is created each time the script runs.
  • Copies each disk into the target storage account using a blob copy with a SAS.
  • Creates new managed disk resources in the target resource group and target location, with the same names as the source disks.

Important notes:

  • Only supports OS disks for now, since I could not be bothered to write code to check if the disks are OS or data. Maybe later…
  • By default the target storage account is PremiumLRS, you can change this in the variables.
  • I use a 3600 seconds (1 hour) duration for the Shared Access Signature. If you think your disk takes longer to copy than that; increase the value in the variables.
  • There is a timeout, set to the same value as the SAS duration, so the script will continue after the copy has been going on for longer.
  • Assumes you have already logged into Azure and selected the correct subscription.
  • Only copies disks within the same subscription.
  • Assumes your target resource group already exists.
  • Neither deletes the temporary storage accounts or the source managed disks. I will not delete your data!
  • Hardly any error checking.
  • Absolutely no warranty whatsoever; use at your own risk!

https://gist.github.com/morgansimonsen/203983b7c52d1fce497c3a9fd4c24b21

M

Active Directory, Azure AD

Azure AD allows duplicate group names

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

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.

  1. First enable SAML SSO for your organization. Just enable it for now and press Save.
    merakisamlsso1
  2. 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:
    merakisamlsso2
  3. On the page of your newly created application select Configure single sign-on.
  4. Select Microsoft Azure AD Single Sign-On as the sign on method.
  5. For your application identifier and reply URL enter https://dashboard.meraki.com.
    merakisamlsso3
    NOTE: We will change the value of the Reply URL in the following steps.
  6. Download the certificate in Base 64 format and open it.
    merakisamlsso4
  7. On the Details tab, find the certificate thumbprint and copy it.
  8. 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:
    merakisamlsso5
    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.
  9. 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:
    merakisamlsso6
  10. 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.
  11. 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.

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

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.

  1. In the Azure AD portal, go to the Attributes tab of the Meraki Dashboard application.
  2. 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.

  1. In the Azure AD portal select the Users and Access tab of the Meraki Dashboard application
  2. Select Show: All Users in the drop down box.
  3. 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.

  1. 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.
  2. Meraki Dashboard show now show up as an available application:
    merakisamlsso8
  3. Hit the icon and you should now be forwarded to the Meraki Dashboard.
  4. Notice that your username at the top is now your User Principal Name from Azure AD.
  5. 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

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:

  1. Log into the Azure AD Portal (manage.windowsazure.com)
  2. 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.
  3. Press the View Endpoints button at the bottom of the screen.
    azureadguid1
  4. In the dialogue that pops up, your GUID is the long sting directly behind login.microsoftonline.com:
    azureadguid2
  5. 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

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 IDLevelSourceTextDescriptionFamily
601InformationDirectory SynchronizationPassword Synchronization Manager has started. Indicates the password sync manager process has started for the specified AD domain.Password hash synchronization/write-back
605InformationDirectory SynchronizationThe following password changes failed to synchronized and have scheduled for retry.



Lists password changes that were note successful.Password hash synchronization/write-back
609InformationDirectory SynchronizationPassword Synchronization service has stopped.Password hash synchronization/write-back
611InformationDirectory SynchronizationDirectory 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
650InformationDirectory SynchronizationProvision 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
651InformationDirectory SynchronizationProvision 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
653InformationDirectory SynchronizationProvision credentials ping start. TrackingID : Password hash synchronization/write-back
654InformationDirectory SynchronizationProvision credentials ping end. TrackingID : Password hash synchronization/write-back
656InformationDirectory SynchronizationPassword 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
657InformationDirectory SynchronizationPassword 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
658InformationDirectory SynchronizationWindows credential sync is disabled in the registryPassword hash synchronization/write-back
659InformationDirectory SynchronizationIsForcePasswordChangeOnLogonFeatureEnabled=Password hash synchronization/write-back
104InformationDirectory SynchronizationExport:: Iteration: <#>, Current batch size: <#>, Exported total: <#>, Successful total: <#>, TrackingId: .ExportObject import/synchronization/export
105InformationDirectory SynchronizationImport:: Iteration: <#>, Current batch size: <#>, Imported total: <#>, More: , TrackingId: , SyncCookie: .ImportObject import/synchronization/export
106ErrorDirectory SynchronizationFailed 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
109ErrorDirectory SynchronizationFailure 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
114InformationDirectory SynchronizationExport cycle completed. Tracking id: Export. This event will repeat for each cycle.Object import/synchronization/export
115InformationDirectory SynchronizationProvisioningServiceAdapter::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
116InformationDirectory SynchronizationCalling 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
116InformationDirectory SynchronizationGetting the current DirSyncConfiguration.Object import/synchronization/export
116InformationDirectory SynchronizationReturned 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
117InformationDirectory SynchronizationImport prefetch:: Start - , End , Idle 00:00:00Object import/synchronization/export
904InformationDirectorySyncClientCmdImport/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
904InformationMicrosoftAzureActiveDirectoryClientStarting: 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.
904InformationAzureActiveDirectorySyncEngineEach event displays one of the install/setup/uninstall steps of Azure AD Connect setup.Setup
905WarningDirectorySyncClientCmdAttempting to obtain Azure AD Sync Scheduler mutex
905WarningAzureActiveDirectorySyncEngineRemoveSqlLocalDbInstance: 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()
906ErrorDirectorySyncClientCmdDirectorySyncClientCmd: invalid command line argument: (INTIAL)
2001InformationADSyncThe service was started successfully.Service
2002InformationADSyncThe service was stopped successfully.Service
6012WarningADSyncThe management agent failed on run profile "Full Import" because the management agent did not import any objects during the run step.
6100WarningADSyncThe 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.
6105WarningADSyncThe 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.
6110WarningADSyncThe 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.
6126WarningADSyncThe 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.
6127WarningADSyncThe 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.
6201InformationADSyncThe 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.
6801ErrorADSyncThe 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"
6803ErrorADSyncThe management agent failed on run profile "Export" because the server encountered errors.
6941ErrorADSyncECMA2 MA export run caused an error.

Error Name:
Error Detail:

Tracking Id: 		DataValidationFailed
InvalidSoftMatch
AttributeValueMustBeUnique
IdentityDataValidationFailed
6943InformationADSyncPassword sync started for management agent .
0ErrorDirectory SynchronizationAn 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!)

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:

aad_ps_adal_before

After:

aad_ps_adal_after

Morgan

Microsoft Azure

Office Modern Authentication (ADAL) and Autodiscover

1 Comment

The introduction of Active Directory Authentication Library (ADAL) support in Office 2013 and Office 265 ProPlus is great news. The Office suite of applications is now able to take advantage of advanced authentication options like federated SSO and MFA. Using ADAL with Office is referred to using Office with modern authentication. Modern authentication was recently made available to everyone and all you need to do to start using it is add three registry keys. You can find all the information you need here:

http://blogs.office.com/2015/03/23/office-2013-modern-authentication-public-preview-announced/

I recently ran into a problem with using ADAL in Office, which I think is a bug. When you try to connect to a new mailbox in Outlook using Autodiscover, and who doesn’t, Outlook is unable to successfully connect to the mailbox. From my testing, this problem is present in version 15.0.4693.1002 of Office 2013/365 ProPlus (a.k.a. March 2015 Update), which is the first version to include ADAL support.

You can look at the change log for Office here: https://support2.microsoft.com/gp/office-2013-365-update

Check your Office version by going to FileAccount and looking at Product Information:

image

The problem manifests itself when using the Account Setup Wizard.You enter your name, email address and password. Outlook queries Autodiscover DNS records for your domain. When your settings have been discovered you are asked to authenticate against the service. This authentication does not used ADAL in my experience, but displays an old fashioned authentication prompt. However, because of the bug, you will never get this far. Instead the wizard will inform you that it cannot find your settings.

To fix this, simply update to the latest version of Office. The most recent update, at the time of this writing, is version 15.0.4711.1003 (a.k.a. April 2015 update).

None of the fixes in this update specifically addresses this problem, as described in this post, but there is some mention about not being able to add a new account if your are using ADAL in Office and the account uses basic authentication in this KB article:

https://support.microsoft.com/en-us/kb/2965218

  • When you enter incorrect credentials for an account that makes some mailbox connections use Active Directory Authentication Library (ADAL) authentication and some connections use basic authentication, you are not prompted to enter credentials again, and Outlook cannot connect to mailboxes by using basic authentication.
  • When you enable the Active Directory Authentication Library (ADAL)-based authentication for Outlook 2013, you may be unable to add Office 365 accounts that use basic authentication. If you have enabled the ADAL-based authentication for Outlook 2013 that has an Office 365 account configured and the account uses basic authentication, you cannot connect to the account.

Anyway; updating resolves the problem.

Microsoft Azure

When configuring the Azure Load Balancer for Remote Desktop Gateway…

Leave a comment

make sure you DO NOT enable Direct Server Return on your endpoint Load Balanced Set:

image

In November of 2014 support was added for Source IP Affinity (also known as session affinity or client IP affinity) in the Azure Load Balancer. Before that it was not compatible with Remote Desktop Gateway. You could sort of load balance your RDGWs but it required you to put every RDGW server in its own cloud service and the use Azure Traffic Manager to load balance. With this approach you could not put your RDGW servers in the same availability set, so you had no guarantee that your gateways would be distributed across fault and update domains. Boldly, or foolishly, depending on your point of view, I decided to try anyway to use the Azure Load Balancer for RDGW, even though I knew it was not supported. Of course it did not work, but when eventually support was added I ran into problems.

After client IP affinity support was added to the load balancer I reconfigured my endpoints of my RDGW VMs:

Set-AzureLoadBalancedEndpoint –ServiceName <cloud service name> -LBSetName “RDGW HTTPS” -Protocol tcp –LocalPort 443 -ProbeProtocolTCP -ProbePort 443 -LoadBalancerDistribution “sourceIP”

Set-AzureLoadBalancedEndpoint –ServiceName <cloud service name> -LBSetName “RDGW UDP” -Protocol UDP -LocalPort 3391 –ProbeProtocolTCP -ProbePort 443 -LoadBalancerDistribution “sourceIP”

The sourceIP value in the LoadBalancerDistribution parameter is the critical one and it can only be set through PowerShell.

But still no connections… I tried all sorts of things. Since this had never worked I didn’t know if it was failing because of a misconfiguration or something in the Load Balancer. The only difference in setup I could find was that  my load balanced endpoints had Direct Server Return enabled. This was something I had decided to try back when I first set it up. There was not much documentation back then about what Direct Server Return actually did. But now there is a description in the portal:

DIRECT SERVER RETURN

Direct server return configures a virtual machine’s endpoint for the floating IP capability required to configure a SQL AlwaysOn Availability Group. This setting is required when using the SQL Always On Availability Groups in SQL Server. This setting can’t be changed after you create the endpoint.

So, not for RDGW at all…

Unfortunately you cannot disable DSR without deleting and recreating your endpoints. After removing and adding them again I was able to connect through the load balancer.

Since traffic to a particular instance behind the load balancer now is determined by the source IP, all traffic from the same IP goes to the same instance, you might experience an uneven distribution of load. Clients behind a proxy or NAT router will all end up on the same instance.

More information:

BTW I wish the Remote Desktop PG would stop putting all their guides in Word docs, would be so much better on a web page…