Skip to content
July 8, 2014

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.

http://technet.microsoft.com/en-us/security/dn753671

Leave a Comment
June 24, 2014

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!

1 Comment
June 17, 2014

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.

Leave a Comment
June 1, 2014

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.

Leave a Comment
May 23, 2014

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.

image

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:

image

Leave a Comment
April 21, 2014

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:

image

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:

image

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:

image

1 Comment
March 13, 2014

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.

Leave a Comment
January 21, 2014

Work Place Join Adventures

I’ve been working in my lab with Windows 2012 R2 AD FS and decided to test Work Place join functionality.

I configured my AD FS with device registration. You can read it here on how to do that.

I installed Web Application Proxy (WAP) and made it available via network to my Surface with Windows 8.1. You can read it here on how to do that.

Also, I configured proper DNS resolution so the device can resolve WAP via proper name. One of the above links talks about it as well.

Then I tried to workplace join my Surface device. It failed. I tried all kind of things to fix it, to no avail. So finally I contacted Microsoft Support and after a few hours of troubleshooting we figured out why it was not working and how to make it work.

What we discovered is that WAP and ADFS servers didn’t have SSL binding for the following name:

EnterpriseRegistration.myfeddomain.com:443

Tip: To see current bindings run this command:

netsh http show sslcert

So when Surface device tried to connect to registration URL, the connection was terminated by the WAP server.

I have four different test ADFS environments and decided to see if all of them had the same issue or not. So I ran that command in all four implementations and saw an interesting pattern.

When ADDS name of the domain where ADFS was installed matched Federation Service name, then the required binding was present. When ADDS name did not match the Federation Service name then the required binding was not there and work place did not work. Ok, if you not follow me, lets take a look at some examples.

Let’s say, my ADDS name is CONTOSO.COM and when I install ADFS, I give it the following name FS1.CONTOSO.COM. Name space of the ADDS and Fed Service is the same. If you look at SSL binding you will find EnterpriseRegistration.contoso.com:443

If we look at a different design, with the same ADDS Domain (CONTOSO.COM), but we install ADFS with different name, such as FS1.MYFEDDOMAIN.COM. If you look at SSL bindings you will not find required name for device registration.

When ADFS is installed with different name then the ADDS name, it does not create required SSL binding.

But, no worries. It is actually easy to add this binding and enable device registration to work. All you have to do is to run two PowerShell commands.

To make it work, first I had to run this on ADFS server:

Add-AdfsDeviceRegistrationUpnSuffix -UpnSuffix “myfeddomain.com”

It added EnterpriseRegistration.myfeddomain.com SSL binding to ADFS server.

Then I had to run this on WAP server to get the same binding registered as well:

Update-WebApplicationProxyDeviceRegistration

In my test environment I have my users in the following naming convention User@myfeddomain.com, and device registration started to work as expected.

Let me know if you got any questions.

1 Comment
November 19, 2013

Access O365 on Demand, Part 3

This is the third installment, please read the prior two posts (Part1 and Part2) to get up to date on what this is all about.

So while the following solution will likely work as described, as far as I know it is not officially supported. So if you implement it and have some issues and contact Microsoft support services, you’ll more likely be asked to reproduce the same issue without external federation.

The following concept design will allow to extend authentication to the external identity providers.

1. First, we federate our O365 Tenant. To do this we will need to have ADDS where we implement DirSync and synchronize accounts from ADDS into Windows Azure Active Directory tenant. Then we install ADFS and federate it with the same tenant.

Now when users try to use accounts for this O365 tenant they will be redirected to the ADFS for authentication.

2. Next, create accounts for external users in ADDS. Link external accounts to their corresponding accounts in ADDS. In this example I’m taking UPN of the external account and put it the “comment” attribute of the ADDS account. This step is obviously the most difficult one in this whole solution. You can do it by hand or come up with some type of Identity Management solution that automates it. As accounts get created in ADDS they will get synchronized into Azure Active Directory via DirSync that was implemented in first step. By default DirSync runs every three hours. If it needs to be more often then you’ll have to trigger it on more frequent schedule.

3. You have to figure out how you are going to activate accounts in O365, as DirSync does not do that for you. You can do it by hand or via PowerShell script.

So far nothing different from any other basic implementation of the O365 and federated ADDS.

4. Next we are going to extend this solution with external Identity Providers. We create normal trust with ADFS acting as RP and external Identity Provider as IdP. One of the super important things to know is that external IdP must be able to provide Authentication Information to the ADFS – ie it must provide information on how user authenticated to IdP and the time stamp of the authentication,  AuthenticationMethod and AuthenticationInstant. For example, none of the Social IdPs are providing such info. Without these assertions it will not work, as O365 requires these assertions.

5. On the incoming trust claims rule of the IdP in ADFS, create the following three rules:

Rule 1:

image

Rule 2:

image

Rule 3:

image

These rules will use incoming UPN from the external IDP and lookup corresponding account in ADDS, and fetch its samAccountName. The result of these rules is the windowsaccountname claim that contains value of the linked user. This claim is used as input claim by the default ADFS O365 claims rules to lookup user UPN and ObjectGUID in ADDS.

That is pretty much all to it.

After implementing above steps, here is how authentication should work:

image

  1. User goes to the https://portal.microsoftonline.com and type their ID for the O365 SharePoint portal (for example, MikeJonesFabrikam@contoso.com)
  2. Since O365 tenant is federated, it redirects user to AD FS. Instead of authenticating directly to AD FS they are redirected to their home IdP – Fabrikam.
  3. They authenticate to their IDP, for example with smart card.
  4. Their home IdP issues required claims and sends user back to AD FS.
  5. AD FS does AD DS account lookup, does all the claim transformations and issue outgoing claims for O365.
  6. User authenticates into O365 with token issued by AD FS.

 

Give it a try and see if it works!

3 Comments
November 16, 2013

Access O365 on Demand, Part 2

This is the second installment on extending access to O365, read the first installment to get a better idea of what I’m discussing here. In the first part I shared what type of functionality this customer wanted and asked if there are any ways to do it.

So before we dig deep into any type of solution solving their needs we need to examine how O365 authenticates users and see if we can use it in our solution.

Probably the main thing to understand about authentication into O365 SharePoint is that it must start at O365 site: https://portal.microsoftonline.com and you must have an account with O365. You can’t start authentication into it from other portals or identity providers (if you know how I’m all ears!).

So the most basic configuration to access the site is to have an account in it and authenticate with this account into the site. The O365 subscription administrator would create such account for the user and provide initial password. The account can be in two different formats:

  1. <yourname>@<tenantid>.onmicrosoft.com
  2. <yourname>@<customerdomainname>

Most customers would add their <customerdomainname> as the suffix in the account name. This is what my customer is doing with their O365 at this moment as well. They create accounts for external users and communicate account information to them. As I discussed in the first part, they would like to get out of manual account creation and account management.

The next possible authentication solution for O365 is the integration with customer on-premises AD DS via DirSync. The DirSync is installed on one of the on-premises servers and it is used to synchronize accounts from on-premises AD DS into the Azure Active Directory. The latest version of the DirSync even can synchronize passwords. User is still authenticating into O365 via O365 based accounts, by typing their user account and password. The good part here is that those users use the same user account (their UPN) and password as they would use on their internal network. With this option, account must be in the form of yourname>@<customerdomainname>, this is required for DirSync functionality.

As you can see, it does not provide any benefit to the problem that my customer is trying to solve. They would still have to create accounts manually and deal with password management.

The third possible authentication solution is to enable federation between O365 and the customer on-premises environment. This is probably most used option in enterprise environments. Federation is added to the configuration with DirSync already in place (in large environments FIM 2010 R2 is used often as well). After federation is added, when user types their user account at O365 logon page, they are redirected to the Identity Provider STS implemented at on-premises customer environment. If user is connected to the internal on-premises environment then they’ll more likely get single sign on (SSO) experience. If they are outside, then they will be prompted to authenticate to their company Identity STS and then they’ll get into O365. The most commonly used STS is AD FS 2.0, but other vendor products supported as well (like Shibboleth).

So we have three options to authenticate into O365. The first option is what my customer is using right now. The second option will not solve their problem. The third option might provide a foundation for what they are trying to do with their strategy to provide access to their O365 SharePoint environment.

The question is, can we do another hop in federation and extend the third option to external trusted Identity providers?

In the next installment I’ll share what I have learned so far in my trial and errors of extending federated O365 to second level Identity Providers.

2 Comments
« Older Entries
Newer Entries »
%d bloggers like this: