First published on TechNet on Nov 21, 2017
Hi, Michele Ferrari here from the Premier Field Engineer-Identity Team in San Francisco here today to do some mix and match about multiple technologies we have within the Azure space.
This is the question we're going to answer today:
How can We use an Azure AD cloud Only Identity to access an OnPrem non-cloud resource?
First of all, we need a resource. We enable remote access to "Work Folders" using Azure Active Directory (great Kudo to our PM Jeff Patterson from the Product Group), secondly I'll show you how you can use a cloud only identity (it only exist in AzureAD) to actually impersonate an OnPrem User Account to access Work Folder. This is made possible by Azure AD Application Proxy which enables Kerberos Constrained Delegation.
Ready? Follow me…
Prerequisites
-
A Microsoft Azure AD basic or premium subscription and an Azure AD directory for which you are a global administrator
-
An Active Directory Domain Services forest with Windows Server 2012 R2 schema extensions
-
Your on-premises Active Directory user accounts are synchronized to Azure AD using Azure AD Connect
-
Note: Device writeback should be enabled if using conditional access
-
-
A Work Folders server running Windows Server 2012 R2 or Windows Server 2016
-
See Deploying Work Folders on TechNet to configure the Work Folders server and sync shares
-
-
A server running Windows Server 2012 R2 or higher on which you can install the Application Proxy Connector
-
A Windows 10 version 1703, Android or iOS client
-
A Server running Windows Server 2012 or 2016 for the Azure AD Application Proxy Connector Make sure the connector's communication with the Application Proxy is not blocked by a firewall. To check that all required ports are open, please try our port check tool. The connector must have access to all on premises applications that you intend to publish.
I'm not going to cover how to Enable remote access to Work Folders using Azure Active Directory Application Proxy as this is already available here:
I'm only providing a high-level overview to get you in the mood (Thanks Jeff):
-
Create a Work Folders proxy application in Azure AD and give users access.
-
Create a Work Folders native application in Azure AD.
-
Install the Application Proxy Connector on an on-premises server.
-
Verify the Application Proxy Connector status.
-
Verify the Work Folders server is configured to use Integrated Windows Authentication.
-
Create an SPN for the Work Folders server.
-
Configure constrained delegation for the App Proxy Connector server.
-
Optional: Install the Work Folders certificate on the App Proxy Connector server.
-
Optional: Enable Token Broker for Windows 10 version 1703 clients.
-
Configure a Work Folders client to use the Azure AD App Proxy URL.
What you achieved so far is the possibility to use Work Folders from everywhere using an OnPrem User Account.
Now, let's see how we can use a cloud only identity to do the same. This identity is not synchronized from Onprem to AAD, I'm talking about impersonate an AD account using an Azure AD user identity
You should now have 2 Apps in AAD:
-
Work Folder Native –native apps running on devices, with no credentials, no strong identity of their own. This is the Work Folder application configured on our internal server, it's in fact a type of client application that is installed natively on a device. It is considered a "public" client within the OAuth 2.0 RFC
-
Work Folder Proxy – Web Application that can have their own credentials, usually run on servers. Think of browser-based web applications or services that are accessed using a browser and/or protocols of the web. This is what allows us to expose the internal Work Folders in a secure way. Defined as "confidential" in the OAuth 2.0 Authorization Framework
Now, to use a cloud only identity to impersonate an OnPrem User Account we use Kerberos Constrained Delegation with the Work Folder Proxy Web App.
Before diving into the nuts and bolts, let briefly summarize what must fundamentally happen for KCD to be successful:
-
The user enters the URL to access Work Folders on-prem through Application Proxy
-
The Application Proxy redirects the request to Azure AD authentication services to pre-authenticate (this can also include MFA). If the user is validated, Azure AD creates a token and sends it to the user
-
The user passes the token to Application Proxy.
-
Application Proxy validates the token and retrieves the Username part of user principal name from it, and then sends the request, the Username from UPN, and the Service Principal Name (SPN) to the Connector through a dually authenticated secure channel.
-
The Connector performs Kerberos Constrained Delegation (KCD) negotiation with the on-prem AD, impersonating the user to get a Kerberos token to the application.
-
Active Directory sends the Kerberos token for the application to the Connector.
-
The Connector sends the original request to the Work Folders server, using the Kerberos token it received from AD
-
The Work Folders server sends the response to the Connector, which is then returned to the Application Proxy service and finally to the user.
Follow me in this further step, in step 4 I'm saying that the Application Proxy retrieves the Username part of the UPN .
Azure AD Cloud Only User: misterMik@ADAL.mistermik.com
OnPrem Account: mistermik@IDENTITY.LOCAL
The user part of the UPN for my cloud only account is: MisterMik @ADAL.mistermik.com
Since we've configured the App Proxy to retrieve only the Username, as long as an account exists in my OnPrem AD with the same Username and it's not disabled, the Connector Server Computer Object will impersonate the user and request a token for it to access the work folders resource.
This is Constrained delegation: client send the Service Ticket to the Server, and server requests the service ticket via S4U2Proxy for the user.
This is the Azure AD user we are going to use to impersonate the OnPrem AD account: MisterMik@ADAL.mistermik.com
This is the OnPrem Active Directory Account which we'll impersonate to access our files on the Work Folders Server. IDENTITY\Mistermik. These accounts have only the "SAMID" which is the same.
We configure the Delegate Login Identity to deconstructs and craft the username part of the user principal account. ( MisterMik@ADAL.mistermik.com ).
AAD-Application Proxy has a few of options regarding which identity should be used when we attempt the KCD. • On prem UPN (e.g. when customers used the alternate login ID) option in Sync and so the on prem UPN is different than the cloud one
• UPN User part only
• samAccountName
We also have an option to request a SPNego Kerberos ticket if needed.
We need to allow the cloud only user to sign-on with our Work Folders Application for the AzureAD Pre-authentication.
We're now ready for the final test. We use a Windows client (in my example a Win 10 1703 in workgroup). We start the configuration for Work Folders.
Here we use the External URL provided by the Work Folders Proxy App:
https://workfolders-mod507542.msappproxy.net/
The Application Proxy, using its Connector will reach out to the internal address:
https://workfolders.identity.local/
We enter the Application Proxy External URL into the Work Folders URL:
User Consent and Application Management. When you registered the Native App, you defined which permissions the app needs access to, and which resources.
Because native clients (Work Folders Native) are not authenticated, an app defined as a native client app can only request delegated permissions. This means that there must always be an actual user involved when obtaining a token.
Web apps and web APIs (Work Folders Proxy) must always authenticate with Azure AD when getting an access token.
As shown in the following snapshot, an OAuth2 authorization request is the first step for your application to get an access token. As part of the authorization process, user consent is involved. User consent is the act of displaying a dialog that clearly lists the permissions that your application is requesting. The user can decide if the permissions your application is requesting should be granted. The permissions that appear in this consent dialog are the same permissions you configured for the Native App.
We must accept the security policies for my client device, which were specified earlier on my Work Folders server. Click I accept these policies on my PC.
Configuration is completed in a few seconds. Data from the server location will get synchronized to the specified folder on my client. Again, this data will be stored in an encrypted way (hence the green color in file explorer when viewing the folder).
Looking at what happened on the Application Proxy Connector Server, it used a delegation normally referred to as S4U, specifically It used the Service-for-User-to-Proxy (S4U2Proxy) flavor of delegation which it is an extension that allows a service to obtain a service ticket on behalf of a user to a different service.
Much about Kerberos has been well documented on TechNet. The two links below can expand your knowledge as far as you would like to take it beyond the scope of this post.
Obviously if the OnPrem Account is disabled or it doesn't exist, the impersonation will fail and the user won't have access to the data. Same result if I restrict access from the AzureAD endpoint prospective, I can block the user before calling the Application Proxy Connector.
This was only an example of the great capabilities of Azure AD Application Proxy and what you can do integrating app in AAD.
That's all! Enjoy having your corporate users' data folders synchronized to your end-user's client device, wherever you are and using only an Azure AD cloud only identity.
Michele Ferrari ( MisterMik )
Premier Field Engineer