All posts by Morgan Simonsen

Introduction

I spend my time working with public cloud services for a large number of organizations. That means many, many different user accounts to keep track of. The tool I use most to interact with these services is the web browser. As you all know browsers try to make life easy for their users, and therefore they cache a lot of information, including logins, cookies and AuthN tokens (these are cookies too). All in an effort to make it easy for an end user to get to his stuff quickly. But we are not end users are we…? For me all this caching is very inconvenient when I need to be someone other than my own identities, which is all the time. And not only that but at the same time that i want to operate as myself. Here is how I have this set up today.

The Browser

For me Google Chrome works best. It has the features I need, simple as that. My reasons are laid out below.

Securing Login Information

I keep all my login information secure in a KeePass 2 database. I choose KeePass 2 because it has good encryption (AES-256), great multi-platform support, lots of plugins, good security features like automatic workspace lock, is open-source and free. I keep my KeePass databases in a cloud storage account protected with Multi-Factor Authentication (MFA). KeePass lets me generate long, complex passwords easily so I never (ever) reuse passwords anywhere.

Accessing Login Information Easily

I mentioned that KeePass has great plugin support. One of my favorite plugins is KeePassHttp, which exposes password entries securely over HTTP. It creates a local HTTP endpoint that authorized clients can talk to. Authorization is controlled in KeePass and is thus protected by the KeePass master password and any other factors you may have chosen.

KeePassHttp together with the Chrome extension chromePass completes this setup by serving up the necessary login information based on URL. chromePass connects to KeePassHttp and retrieves the login information from the KeePass database that matches the URL of the site you are visiting. If several entries match you get a list to choose from. By default KeePass will not just serve up the login information, you have to approve it from a prompt displayed by KeePass.

Multiple Personalities – in a good way

The final piece of the puzzle is the Chrome plugin MultiLogin. It takes care of the problem of the browser trying to cache your login information and state in cookies. Whenever you hit the MultiLogin button Chrome starts a completely clean browser tab that is not related in any way to what is going on in any other tabs. Each new MultiLogin tab is identified by a number so you can easily tell them apart. All tabs with the same identifier share the same state, so you can have several tabs where you are the same user. Everything in the MultiLogin tabs is destroyed when you close Chrome so nothing will be remembered.

I use regular Chrome tabs for my own private web surfing, and Chrome caches my logins and stores cookies just like normal. For everything else I use MultiLogin tabs. This also has the added security benefit of never storing any session or AuthN cookies when you close Chrome.

Unfortunately the developer has removed MultiLogin from the Chrome Store for unknown reasons, and I have not been able to find a replacement. I was lucky enough to install it when it was available, so thanks to Chrome’s roaming extension feature I get it on all my computers. If you still want to get MultiLogin there are instructions here for installing it manually.

UPDATE 27.10.2016: A new Chrome extension called openMultiLogin has been released that replicates the functionality of MultiLogin. Check it out in the Chome extensions store.

This is slightly off topic for me, but because I spent quite a bit of time on figuring it out and could not find this documented anywhere else, I thought I would write it up quickly.

At some point I could no longer install any new apps from the Windows Store on my Surface 3 Pro Windows 10 machine. Apps already installed would update fine, but new ones could not be added. The error was:

“Try that again. Something went wrong. The error code is 0x8007001, in case you need it”.

If we translate that number to a human readable form we get:

Incorrect function.

Not much to go on. I initially thought this was something to do with either the modern app framework or Windows installation and tried things like resetting the store with (WSReset.exe) and scanning the system files with SFC.EXE. None of these things helped. In the end it turned out that is was related to my SD card. I had an SD card installed and had previously moved a few apps to it. Apps that were so large that I didn’t want them eating up my system drive. Moving these apps somehow caused all new apps from then on to try to install on the SD card, or at least rely on it for something during the install. I shut down the computer, removed the card and could then install apps again. At this point I also reinserted the card and could now also install new apps with the card inserted. Some setting somewhere had obviously been changed. I do not know the root cause of this behavior, which is always annoying, but I am prepared to accept that I made it work.

Updating already installed apps worked because they were all on the correct (C:) drive. The default install location for apps was also set to the C: drive, which makes this even stranger…

Microsoft is working on creating a unified OneDrive Windows sync client for both consume OneDrive and OneDrive for Business. This is very good news and you can read all about it here.

But the download links on the Office support pages are not for the latest version of the Next Generation Sync client (ODNGSC). At the time of this writing the latest version is 17.3.6349.0306, but the download link is for 17.3.6302.0225. So why does this matter? The ODNGSC updates itself as part of an Office 2016 update cycle or individually. When you deploy the client you might have some issues that are blocking you, stopping you from completing setup. If that is the case the client cannot update itself, because initial setup has not been completed. So you can’t get the version that might fix your setup problem. Catch 22.

Right now, one such problem is trying to use ODNGSC in Azure RemoteApp (ARA) images. In ARA users’ profiles are redirected to profile disks (VHDs) stored in Azure storage accounts. The redirection happens by using a reparse point linking the VHD to the user’s %USERPROFILE% path. The ODNGSC will not accept a path that includes a reparse point so you cannot install the client. If this error was fixed in a more recent release than the one currently installed or available for download, you would face the above problem. (So right now, this trick does not help you, but it serves to explain why I wanted to get to the latest client binaries.)

To work around this and perform initial setup with the latest ODNGSC, do this:

As an e-Resident you are issued a secure digital identity by the government of Estonia. This enables you to use services provided by the Estonian state agencies and private sector. Thing you can do:

Establish a company online
Estonian companies can be established, registered, and administered entirely online.

Open a bank account in Estonia
Estonia is well-known for its user-friendly and secure online banking. The e-Resident smart ID card is approved by LHV, Swedbank and SEB banks in Estonia, with others planned in future.

Digitally sign documents and contracts
Digital signatures have been available in Estonia since 2000 and are used daily. More than 200 million digital signatures have been created in Estonia since inception.

As someone interested in digital identities I think this is fantastic stuff, and heralds the coming of a new age of business. Looking forward to visiting the Estonian consulate in Oslo to pick up my ID card.

I was helping a customer set up a hybrid Exchange environment recently. When the time came to run the Office 365 Hybrid Configuration Wizard we received this error:

The error given is:

The UTC time represented when the offset is applied must be between year 0 and 10,000.Parameter name: offset

I asked the Internet and quickly discovered that this is not a Hybrid Configuration issue, but rather some bug in the .NET framework DateTime function. I soon found this page (quite old as you can see). To quote the author: The value of DateTime.MinValue cannot be cast to a DateTimeOffset if you are east of London!

So the solution in our case was to temporarily set the time zone of the server where we ran the Hybrid Configuration Wizard to UTC (Coordinated Universal Time), aka. GMT.

Windows 10 introduces the ability to join a computer to the cloud directory service Azure AD. This is very similar to the traditional domain join, where you join a computer to an Active Directory domain, run on-premises by one or more Domain Controllers. Both operations lets the computer operate within a common security context and benefit from Single Sign-On (SSO) to all resources that share the same security context. However, joining Azure AD instead of a traditional domain can break things or make them more difficult. There are many examples of this, but the one I want to discuss here is connecting with Remote Desktop (RDP) to an Azure AD joined computer with a user account from Azure AD. Just to be clear; the connection we want to establish is to an Azure AD joined computer, logging on with an account from Azure AD. This account can either be synced from on-premises or be mastered in the cloud, and both federated and password logons are supported. We do not depend on any local accounts on the computer, using tricks such as adding an Azure AD work account to a local account or a Microsoft Account (MSA), this is pure Azure AD.

Connecting Successfully

There are some obvious prerequisites for this to work:

The computer must be joined to Azure AD

Remote Desktop connections must be enabled and allowed through the host firewall

Any other firewall between you and the computer must allow the Remote Desktop protocol

The key to connecting is having Windows 10 present an desktop login screen:

That means that we must disable any form of single sign-on or integrated authentication. This requires the following steps:

On the Windows 10 computer; disable Network Level Authentication (NLA) for Remote Desktop Connections
Open System Properties and navigate to the Remote tab. Under Remote Desktop; make sure Allow remote connections to this computer is enabled, and that Allow connections only from computers running Remote Desktop with Network Level Authentication is unchecked.This will disable the ability on the host to require that authentication happens before a user session is created.

On the computer you are connecting from create an RDP file and add the following settings to it:enablecredsspsupport:i:0authentication level:i:2
Again, these settings disables sending any credentials automatically to the host computer. Leaving Windows with no choice but to display a desktop logon screen. The easiest way to create an RDP file is to open the remote desktop client, enter the name or IP of the computer you want to connect to and then his Save As. This will produce an RDP file that you can add/edit the necessary settings in. For those interested, most of the settings you can specify in an RDP file are listed here. In theory you could also add these settings on the command line, but I have not worked that out.

The last trick to make this work involves the username you specify on the logon screen. It must be in the following format:

AzureAD\<full UPN in Azure AD>

e.g. AzureAD\morgan.simonsen@langskip.no

This is a non-intuitive format for those of us who have connected to Windows over RDP in the past, but it is what works. I have not been able to connect with any other combination of domain, username, DNS domain or UPN, but this may very well change soon.

UPDATE 2015-11-7: On Windows 10 build 10586 the AzureAD prefix is no longer needed. You can just use your UPN.

Closing remarks

When you are joined to Azure AD we are naturally also authenticating against Azure AD, but it might be that you have federated Azure AD against an ADFS server, in which case authentications are redirected back to on-premises. Depending on your setup for authentication you will see the following differences:

Azure AD authenticated users will display the logged on user as: AzureAD\<concatenated display name>. Federated tenants will display the logged on user as <on-premises NetBIOS domain name>\<on-premises sAMAccountName>. This difference is visible if you use the whoami utility or look at the environment variables. Just to be clear, these differences do not have anything to do with remote desktop connections, they are just a consequence of joining Azure AD.

Connecting with a local account to a Windows 10 computer joined to Azure AD would as it does for any other Windows computer.

This is probably not how Microsoft would like us to connect to Azure AD joined machines so we can expect NLA authenticated connections to work some time in the future.

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.

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.

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:

Azure AD B2B and B2C: The next generation collaboration has arrived
Level: 300
Azure AD Business-2-Business and Business-2-Consumer are two new features of the global trust fabric that is Azure Active Directory. With Azure AD B2B many of the identity challenges of collaborating with partners are no longer relevant. The complexities and cost of federation, and the security issues with maintaining accounts for your partners are no longer necessary. Join me to learn how to use these new features to allow anyone you choose to securely use your applications and access your data. We will also cover B2C where Azure AD finally integrates with the major social identity providers like Google, Microsoft Accounts and Facebook to allow you to share data and applications with consumers.Azure AD Domain Controller Services (DC-as-a-Service): Get rid of Windows Server AD once and for all
Level: 300
Azure AD offers the next generation identity platform built from the ground up to enable the cloud. As more and more organizations adopt and move to Azure AD the need for the traditional Active Directory infrastructure dimishes. But it can be very hard to get rid of our oldest AD dependent applications. With Azure AD Domain Controller Services we can finally take this last step and retire our old domain controllers. Azure AD DCaaS can use Azure AD to emulate a domain controller and thus let us run all our legacy applications while only using Azure AD. Join me in this sessions for a highly technical overview of this new technology.

Group Policy has been with us for well over 12 years now and has turned out to be a good tool for deploying configurations to your users, servers and clients. A summary of Group Policy in general is beyond what I want to say here so for anyone looking for that before reading on have a look here.

A major tenet of Group Policy and Active Directory site, domain and OU design is to group users by common denominators and configure Group Policy for them. For instance you might want to use a geographical approach and group your users according to geograpihal location. All users from Europe in one OU and all from Asia in another. Each would get a GPO setting the common configuration that all users in any give location should have. Another approach would be to group by function. Lets say we place all users beloning to our R&D deparment in one OU, regardles of physical location.