Skip to content

Pass the Hash White Paper v2

Updated version of the Pass-the-Hash white paper was just released. Good read to know how to protect your ADDS environments from this attack.

About these ads

Azure AD Application Proxy

In the last few days there were some interesting previews lighted up in Azure AD – one of them is Azure AD Application Proxy. This is very unique service which will allow you to publish your on-premises applications to external users via Cloud based SaaS reverse proxy solution. Currently it is in preview and it provides very basic functionality, but this is great concept and we’ll have to see what type of new features they will add to the service over the coming weeks and months.

To read more about it you can visit this post.

To enable Azure AD Application Proxy you’ll need to have an Azure AD Premium subscription. The great news is that you can now get a free 90 day trial of the AAD Premium. Check out this video on how to do that.

How to enable Azure AD Premium Trials


Not directly related to the AAD, another interesting preview is RemoteApps feature provided via Azure Cloud Services. I just turned on the trial for it and will need to play with it a bit over the next few weeks.

Good day!

Logging into AAD via 3rd level Federated Account

There are two common ways to authenticate into Azure O365:

  1. With non-federated account, residing in AAD, as I call it, with “managed account”, where user is authenticated against AAD using user ID and password, and with
  2. Federated account, with shadow account residing in AAD, and the account that user authenticates against, residing in the on-premises environment.

With “managed account” there are not many options, you basically authenticate against AAD, maybe have MFA on it as well. With federated account there are many variations come into play, mainly around the vendor product is being used to provide the identity provider services. AD FS is one of the most common products, but many other have been certified to provide such service as well. This topology usually assumes that user authenticates against directory where identity provider is installed. There is currently no easy way to log into the Azure via a second level Identity Provider, ie, the Identity Provider that is trusted by be on-premises IdP.

One of such ways I discussed in my blog posts back in the fall of 2013. The idea is that we register external identity provider identities in our on-premises AD DS, then use DirSync to get these registration accounts into AAD. We use AD FS to transform token from the external identity provider to use AD DS based accounts and get them authenticated into AAD. You can check out more detailed explanation on how it can be done here.

While this works, I feel like this is a bit heavy solution to provide access to the external users to AAD. Users must have accounts in on-premises AD DS, DirSync must be implemented, which means that newly registered accounts won’t be able to access AAD for quite some time. The default DirSync schedule is 3 hours and while it can be reduced, it is usually not recommended to reduce it to a small number.

So couple month ago I started thinking about other ways to use currently available technologies and be able to access AAD via external identities without using DirSync and without storing registration accounts in on-premises AD DS.

GraphAPI comes to the rescue. With GraphAPI developer can write an application that creates accounts straight in the AAD, so it is available immediately after account was registered. This is good, but how do we authenticate against it without having on-premises account? To solve this problem we can use the power of AD FS, some development and GraphAPI. As you probably know, AD FS provides support for custom attribute stores (CAS). CAS is basically a way to pull information about the user from external data stores (not from AD DS, AD LDS or SQL), like text files, other LDAP directors, or as you can guess where we are going, from the AAD itself. All we need to do is to write CAS that uses GraphAPI to query our AAD Tenant for user information and then builds a SAML token that will be passed to the AAD for authentication.

To do this we need to create a mapping between the external identity and the AAD based account. One of the easiest way of doing this is to take user Name Identifier claim from the external IdP, make sure its value is less than 64 characters and put in into the ImmutableID attribute of the user account in AAD – this should be done during registration of the user in AAD. As part of registration unique UPN will be generated as well, this is a required attribute of the user account.

After the mapping between the external account and AAD account is done, we’ll configure CAS to use Name Identifier as the lookup value of the user account in the AAD to find its corresponding UPN. Now AD FS will have required information to build the outgoing SAML token to authenticate to AAD – user UPN and ImmutableID.

Smart Card Enrollment

A few days ago one of my friends asked if I knew how to enroll smart cards from Windows AD CS without using any type of specialized smart card management systems. I have done this type of enrollment a few years ago, but truth to be told, all of the enterprise environments usually use smart card management systems and I have not seen anyone using out of the box enrollment capabilities. I looked on the Internet, nothing came in the search then I remembered that I might have sample configuration somewhere in my my archives.  So I found in my archives configuration steps on how to enroll a smart card from AD CS and tested it in my lab. It was not a straightforward test, at first I could not make it to work. My test environment is running in Azure IaaS and my physical PC where I attach smart card is not part of the AD DS of the test environment, so in order to enroll from the Enterprise Issuing CA I use RDP connection to one of the workstations in the Azure IaaS environment. The workstation in IaaS did not recognize my Gemalto .NET smart card. It supposed to detect it via plug-play and install the drivers, but it did not do so. It took me a few tries and tests to figure out that I had to download proper drivers and install it manually. Then everything worked beautifully and I was able to enroll my test smart card with a cert for my test user.

You might ask, what is the configuration on ADCS to make it all work? I don’t want to dig in my archives again if I ever want to remember how to do this, so I decided to share it here.

Assumption: I assume that you already have Enterprise Issuing CA implemented in your environment. In current day and age I would recommend you to have it on Windows 2012 R2, but it will work on 2008, 2008 R2 and 2012 versions as well. It might even work against 2003 based OS, but that is too ancient by now and I hope everyone is moving to the latest greatest OS.

OK, you have AD CS running, to enroll a user with a smart card certificate we are going to use “Enroll on Behalf” concept. What it means is that we are going to designate one user (SC-Enroll user account in the following steps) with special permissions to enroll smart cards for other users in the environment. Usually it would be someone from the security department. To configure and then issue user cert to a smart card do the following steps:

  1. Configure Enrollment Agent Template
  2. Configure Smart Card Logon Template
  3. Assign created templates to Contoso Issuing CA
  4. Enroll for Enrollment Agent certificate
  5. Smart Card Certificate Enrollment for the end user


Configure Enrollment Agent Template

  1. Log on as Administrator to ADCS server.
  2. Open Certificate Authority MMC
  3. Right click on Certificate Template and click Manage
  4. It will open the Certificate Templates MMC (Certtmpl.msc).
  5. In the details pane, right-click on Enrollment Agent, and then click Duplicate Template.
  6. Choose “Windows Server 2012 R2” template.
  7. On the General tab, enter the Template display name as Contoso Smart Card Enrollment Agent, and then click Apply.
  8. Click on Security tab. Click on Add button. Type SC-Enroll and click on Check names button. Click OK. Give it Allow Enroll permission.
  9. While in Security tab select Domain Admins and uncheck Enroll check box.
  10. While in Security tab select Enterprise Admins and uncheck Enroll check box.
  11. Click OK to save and close Contoso Smart Card Enrollment Agent template.


Configure Smart Card Logon Template

  1. In the details pane, right-click on Smartcard Logon, and then click Duplicate Template.
  2. Choose “Windows Server 2012 R2” template. Click OK.
  3. On the General tab, enter the Template display name as Contoso Smart Card Logon, and then click Apply.
  4. Click on Issuance Requirements tab. Enable checkbox “This number of authorized signatures:” Make sure it requires only one (“1”) signature.
  5. Under Policy type required in signature select: Application Policy
  6. Under Application Policy select: Certificate Request Agent
  7. Under Cryptography tab, select “Requests must use one of the following providers:” and then select “Microsoft Base Smart Card Crypto Provider
  8. Click on Security tab. Click on Add button. Type SC-Enroll and click on Check names button. Click OK. Give it Allow Enroll permission.
  9. While in Security tab select Domain Admins and uncheck Enroll check box.
  10. While in Security tab select Enterprise Admins and uncheck Enroll check box.
  11. Click OK to save and close Contoso Smart Card Logon template


Assign created templates to Contoso Issuing CA

  1. Switch back to Certificate Authority MMC
  2. Right click on Certificate Templates, click New and Certificate Template to Issue.
  3. In selection window select newly created templates (Contoso Smart Card Logon and Contoso Smart Card Enrollment Agent) and click OK.


Enroll for Enrollment Agent certificate

  1. Logon to Enrollment Station (this is computer in the same domain where Issuing CA is implemented) as SC-Enroll
  2. Open MMC and add Certificates snap-in for the current user.
  3. Right click on Personal and select All Tasks and click on Request a New Certificate
  4. Click Next
  5. How many templates SC-Enroll have rights to enroll?
  6. In Request Certificates dialog box select Contoso Smartcard Enrollment Agent check box. Click on Details and click on Properties button.
  7. In General tab, type the Friendly name for this certificate (for example: Contoso SC-Enroll Certificate)
  8. In Description type the following: This cert is used issuing Smart Cards to users
  9. Click Apply button.
  10. Explorer other tab but do not change any properties.
  11. Click OK to close the Certificate Properties.
  12. Make sure Contoso Smartcard Enrollment Agent is still selected and click on Enroll button.
  13. Since we didn’t require Certificate Manager Approval, the certificate should be issued and the installation result status should be Success.
  14. Click Finish.
  15. Open Personal certificate store and verify that certificate is present. Open it and verify that private key is present on this computer.


Smart Card Certificate Enrollment

  1. Logon to Enrollment Station as SC-Enroll. Insert Smart Card reader into USB port.
  2. Insert Smart Card into the smart card reader.
  3. Open MMC and add Certificates snap-in for the current user.
  4. Right click on Personal and select All Tasks, click on Advanced Operations and click on Enroll on behalf of
  5. Click Next
  6. In Select Enrollment Agent Certificate click on Browse button, select Enrollment Agent certificate and click OK
  7. Click Next
  8. In Request Certificates select Contoso Smart Card Logon template and click Next
  9. In Select a User click on Browse button, type “User Name” (the user you need to enroll the smart card for…) and click on Check Names, click OK
  10. Click on Enroll button. You should be prompted to provide the PIN for inserted smart card. Type the PIN number and it will be enrolled with the certificate for “User Name” user account from AD DS.
  11. When asked to enroll for next user cancel it.
  12. Open command prompt and type the following command: Certutil –scinfo
  13. Type PIN number when prompted. You’ll see information about enrolled certificate on the smart card.


Smart card is ready and can be used for authentication.

Multiple AAD as RPs with Single AD FS?

In my last post I discussed how we can configure multiple Azure AD tenants as Identity Providers with the same AD FS instance.

This time I decided to reverse the situation and see if we can configure multiple Azure AD (AAD) tenants as relying party with the same AD FS instance, so the AD FS acts as an Identity Provider and allow Single Sign On experience into the Cloud based applications hosted by different AAD tenants. The desired configuration is shown in the following diagram.


The process to enable SSO into Azure AD tenant via on-premises AD FS is well documented and I’m not going to get into all the details, at the high level it is fairly simple and straightforward:

  1. You need to configure custom domain in your AAD tenant.
  2. You run couple PowerShell commands from your AD FS server. The first one will connect to the specified AAD tenant. The second will convert target custom domain for SSO and it will configure AD FS to act as Identity Provider against AAD.
  3. You’d also need to have some type of solution that synchronizes accounts from on-premises ADDS to the AAD Tenant, like a DirSync.

So I did this on my first AAD tenant and was able to SSO into it by using credentials from on-premises ADDS.

Then time came to configure second AAD tenant for SSO, and unfortunately it did not work for me. The PowerShell conversion complained about AD FS Identifier being already in use. I was hoping for a bit more granularity, and be able to configure each AAD as its own Relying Party with the same AD FS, but not the case. Maybe there will be something there in the future that would allow us to do this.

Until we have some workaround and maybe there is one out there already, please share if you know, there has to be one-one relationship between AD FS IdP and AAD RP, like this:


Multiple AAD with the same ADFS Service

A few month ago I discussed how to configure Azure Active Directory as Identity Provider to AD FS and access claims enabled applications. The following diagram shows that specific configuration:


What I didn’t realize at the time is that it is not possible to configure multiple AAD Tenants as Identity Providers with the same AD FS service. The reason it is not possible to configure multiple AAD Tenants is because all of them are using the same Azure AD Signing Certificate. AD FS does not allow different IDPs that use the same signing certificate. Basically, you can have only one AAD Tenant in direct trust relationship with the same AD FS Service, like shown in the following diagram:


Fortunately, there is a fairly easy way to get around this with the current capabilities of Access Control Services (ACS). ACS does not have this certificate limitation and each ACS instance has its own signing certificate. So if you need to configure multiple AAD Tenants as IDP with the same AD FS Service you will need to configure separate instance of ACS for each of your AAD Tenants, configure them with trusts, then configure each ACS as IDP with your AD FS Service. The following diagram illustrates this workaround:


Azure AD Blog Posts

In case you were not aware of the following couple blogs, want to bring them to your attention. Great source of information on what happening with Windows Azure Active Directory.

All of the recent developments with Azure AD are very exciting. The central application access panel I think is going to be used a lot and will provide very convenient way to publish and access hundreds of different applications. As of today it provides access to 926 applications. When it was first introduced back in the summer of 2013, I think it had only about 30 applications. At some point it will probably provide access to most known apps out there in the wild, and I’m hoping that it will allow to put your own LOB apps on the same page as well.


Get every new post delivered to your Inbox.