April 17, 2015 at 10:16Tablet and domain: unity and struggle of opposites
Let's imagine a scenario that is quite common today. A number of business applications are deployed on the corporate network. These applications are published for external access via HTTPS. Mobile employees of the company, being outside the corporate network, want to connect to these applications from their personal tablets running under Windows, iOS or Android. These devices either cannot be included in the domain, or users simply will not do this. How to increase the security of access from such devices to corporate applications? The Device Registration Service (DRS) in Windows Server 2012 R2 can help.
In this article, I will focus on the basic principles and architecture of DRS. Setting details can be found in the fourth module of the course “Corporate devices. How to manage hybrid credentials . ”
Inside the corporate network there is a web application with HTTPS access, published for connecting from the outside. Connected from any platform from any browser, all traffic between the browser and the application is encrypted, what more could you want. But with all the obvious advantages of modern mobile devices, tablets in particular, there is a downside. What is convenient to carry with you everywhere can easily be lost or stolen. Any new “owner” of a device of curiosity, for the sake of or by malicious intent, can try to “learn” URLs in the browser history. And with the saved cookies, which are most likely used on personal devices, it will not be difficult to gain access, including to the organization’s applications.
In a domain network, group policies can easily avoid such situations. Starting with the password for the login to the domain device, ending with certificates for authentication when accessing the application. What about devices that cannot be included in the domain? The approaches can be different: you can configure the mandatory use of a password or PIN code to enter the device, you can generate and install a certificate on the tablet. Only for different platforms, these procedures are different, it will have to be done manually and probably by IT staff, and each new device generates an appropriate chain of actions. And I want the owner of the device to be able to cope with such a task, and then, when there really is a need for it.
One solution is to use DRS from Windows Server 2012 R2.
As the name of the service implies, DRS implements a device registration procedure. During the registration process, DRS generates an X.509 certificate, which is downloaded to the device, and also creates a new object in Active Directory containing information about both the device and the user who completed the registration.
Each time a user connects to the application from a registered device, the user is authenticated (either he enters a password or a cookie is used) and the certificate is verified. And only if both checks are successfully passed, the user gets access to the application. In fact, we are dealing with two-factor authentication.
But it is important to note a few points:
In Windows Server 2012 R2, DRS is installed with ADFS. ADFS, as can be seen from the figures above, plays a key role in the authentication process. To use the registration service for the application, you mustconfigure authentication through ADFS. Since, for security reasons, a server with ADFS is usually located inside the corporate network, a proxy component is needed in the perimeter zone, which will receive requests from the Internet and redirect them to ADFS. Web Application Proxy (WAP) can play a proxy role, a new service in Windows Server 2012 R2. ADFS, in turn, performs user authentication and, if device registration is configured, certificate verification. In case of successful authentication, ADFS generates an access token for the requested application and returns the token to the browser on the user device. After which the user gets access to the application.
If we talk about infrastructure requirements, to use DRS, you must expand the AD schema and have at least one server with Windows Server 2012 R2 and the ADFS role elevated.
The device registration process is shown in the following figure.
Let's see how this process looks from the point of view of the owner of a tablet with Windows 8.1, and what happens behind the scenes. SharePoint 2013 will act as a corporate application. In my infrastructure, ADFS is configured in such a way that device registration is required only if the device is outside the corporate network. If the tablet is connected, for example, to corporate Wi-Fi, then authentication with a username and password is sufficient. And, of course, nothing is required from the user at all if he accesses the application from a domain computer on the corporate network. There is a full Single Sign-On. The ability to configure such conditional access conditions, and for a particular application, is another serious advantage of using ADFS for the scenario in question.Corporate devices. How to manage hybrid credentials . ”
So, an employee of the company is located outside the company and in the browser of a tablet that is not included in the domain, dials the URL of the SharePoint corporate portal. The request through WAP is redirected by ADFS, and we see such a picture.
As you can see, the elements of the ADFS authentication page, as well as error message pages (picture, logo, message texts), are configured. The user specifies the username and password of his domain account, and the login is entered in the format of User Principal Name (UPN). Since the device has not yet been registered, access is denied.
In the text of the error message, I indicated the actions that the user must perform to register the tablet. These actions are different for different platforms. So for iOS you just have to go to the URL: https: // <adfs server name> / enrollmentserver / otaprofile . For Windows 8.1, registration is provided in the OS interface: PC Settings-> Network-> Workplace . And called Workplace join .
By clicking on the Join button , we will see the already familiar ADFS authentication window.
How does Windows 8.1 detect ADFS? From the UPN entered by the user, the suffix is taken, in this case, contosomsspb.com , the predefined name is attached to it, enterpriseregistration and the FQDN is obtained,enterpriseregistration.contosomsspb.com , which the OS is trying to resolve to IP. Accordingly, for such a DRS discovery mechanism to work, you must register in the public DNS domain of the organization A record with the name enterpriseregistration and the IP address of the pox component, for example, the WAP server.
If the password is entered correctly, the device is registered, and we return to the previous window, where you can notice that the Workplace join operation is completed.
What is going on behind the scenes? On the tablet itself, using the Certificates snap-in, you can detect the appearance of a new certificate.
It is he who will now be used as the second authentication factor when connecting to the application.
In Active Directory, the corresponding certificate object can be found in the new RegisteredDevices container . The name of the object matches the CN certificate. Attributes of this object can be viewed, for example, using ADSI Edit.
Among the attributes we will find the device name, OS type and version, the SID of the user who completed the registration, the date and time of registration, etc.
We try to connect to the portal again, get to the ADFS page again, enter the credentials of the AD account again. But now, in addition to password verification, certificate verification and access to the application have been successfully completed.
Moreover, after the first successful connection, the user receives an SSO for this application. He can close the browser, restart the machine, open the browser again, type the URL and ... access the application without any additional questions. Indeed, cookies provide the first authentication factor, and certificate the second. Naturally, not forever, and from time to time the user will have to confirm his authenticity by entering a password. But this term controls IT.
Let's get back to the lost / stolen tablet situation. If the device is already registered, SSO is implemented for the application, and the device fell into the wrong hands. The first line of defense is the password or PIN code to enter the device. For non-domain devices, mandatory locking can be enabled, for example, through Microsoft Intune or another MDM solution. If this has not been done? It turns out that we gave the attacker additional trump cards - he just needs to open the browser and type the URL. Obviously, in such a situation, the owner should notify his IT service as soon as possible. What will IT do then? Let's look at a few options.
If the device registration service is not used at all.
Both solutions, as well as other options that can be offered, are quite applicable, but not ideal.
If the device has been registered.
It is enough for the administrator to find the object associated with the lost device in AD and either delete the object or set the value FALSE in its properties for the msDS-IsEnabled attribute.
Then, when connecting to the application, the device certificate will not pass verification, and the user will receive an error message. Thus, we block access to a specific device.
Well, if the user's password is compromised and became known to the attacker? Nothing will stop him from re-registering. One way to counter this scenario is to use the Microsoft Azure Multifactor Authentication (MFA) service to register your device. In this case, when registering the device, the user, in addition to entering the password, will need to pass an additional check - answer an incoming call to his mobile phone, either enter the SMS code received, or use a special application (Multi-Fator Auth), which again is in the online store Microsoft, Google and Apple.
But this is a topic for another discussion.
So, the device registration service, introduced in Windows Server 2012 R2, will help provide an additional level of security when connecting remotely to corporate applications from personal mobile devices that are not included in the AD domain and are running various OSs.
Details on installing and configuring ADFS and DRS can be found, for example, here .
Configuration features for iOS devices, creating conditional access policies, deploying WAP, etc.:
https://technet.microsoft.com/en-us/library/dn280939.aspx
In this article, I will focus on the basic principles and architecture of DRS. Setting details can be found in the fourth module of the course “Corporate devices. How to manage hybrid credentials . ”
What is the main problem?
Inside the corporate network there is a web application with HTTPS access, published for connecting from the outside. Connected from any platform from any browser, all traffic between the browser and the application is encrypted, what more could you want. But with all the obvious advantages of modern mobile devices, tablets in particular, there is a downside. What is convenient to carry with you everywhere can easily be lost or stolen. Any new “owner” of a device of curiosity, for the sake of or by malicious intent, can try to “learn” URLs in the browser history. And with the saved cookies, which are most likely used on personal devices, it will not be difficult to gain access, including to the organization’s applications.
In a domain network, group policies can easily avoid such situations. Starting with the password for the login to the domain device, ending with certificates for authentication when accessing the application. What about devices that cannot be included in the domain? The approaches can be different: you can configure the mandatory use of a password or PIN code to enter the device, you can generate and install a certificate on the tablet. Only for different platforms, these procedures are different, it will have to be done manually and probably by IT staff, and each new device generates an appropriate chain of actions. And I want the owner of the device to be able to cope with such a task, and then, when there really is a need for it.
One solution is to use DRS from Windows Server 2012 R2.
What is the main idea?
As the name of the service implies, DRS implements a device registration procedure. During the registration process, DRS generates an X.509 certificate, which is downloaded to the device, and also creates a new object in Active Directory containing information about both the device and the user who completed the registration.
Each time a user connects to the application from a registered device, the user is authenticated (either he enters a password or a cookie is used) and the certificate is verified. And only if both checks are successfully passed, the user gets access to the application. In fact, we are dealing with two-factor authentication.
But it is important to note a few points:
- The registration procedure is as simple as possible and does not require preliminary configuration of the device by an IT specialist.
- DRS supports various platforms:
- Windows 8.1 and higher
- iOS 6 and above
- Android - Samsung KNOX
- Windows 7 Pro (included in the domain)
- DRS does not require PKI deployment
What does it look like?
In Windows Server 2012 R2, DRS is installed with ADFS. ADFS, as can be seen from the figures above, plays a key role in the authentication process. To use the registration service for the application, you mustconfigure authentication through ADFS. Since, for security reasons, a server with ADFS is usually located inside the corporate network, a proxy component is needed in the perimeter zone, which will receive requests from the Internet and redirect them to ADFS. Web Application Proxy (WAP) can play a proxy role, a new service in Windows Server 2012 R2. ADFS, in turn, performs user authentication and, if device registration is configured, certificate verification. In case of successful authentication, ADFS generates an access token for the requested application and returns the token to the browser on the user device. After which the user gets access to the application.
If we talk about infrastructure requirements, to use DRS, you must expand the AD schema and have at least one server with Windows Server 2012 R2 and the ADFS role elevated.
The device registration process is shown in the following figure.
Let's see how this process looks from the point of view of the owner of a tablet with Windows 8.1, and what happens behind the scenes. SharePoint 2013 will act as a corporate application. In my infrastructure, ADFS is configured in such a way that device registration is required only if the device is outside the corporate network. If the tablet is connected, for example, to corporate Wi-Fi, then authentication with a username and password is sufficient. And, of course, nothing is required from the user at all if he accesses the application from a domain computer on the corporate network. There is a full Single Sign-On. The ability to configure such conditional access conditions, and for a particular application, is another serious advantage of using ADFS for the scenario in question.Corporate devices. How to manage hybrid credentials . ”
So, an employee of the company is located outside the company and in the browser of a tablet that is not included in the domain, dials the URL of the SharePoint corporate portal. The request through WAP is redirected by ADFS, and we see such a picture.
As you can see, the elements of the ADFS authentication page, as well as error message pages (picture, logo, message texts), are configured. The user specifies the username and password of his domain account, and the login is entered in the format of User Principal Name (UPN). Since the device has not yet been registered, access is denied.
In the text of the error message, I indicated the actions that the user must perform to register the tablet. These actions are different for different platforms. So for iOS you just have to go to the URL: https: // <adfs server name> / enrollmentserver / otaprofile . For Windows 8.1, registration is provided in the OS interface: PC Settings-> Network-> Workplace . And called Workplace join .
By clicking on the Join button , we will see the already familiar ADFS authentication window.
How does Windows 8.1 detect ADFS? From the UPN entered by the user, the suffix is taken, in this case, contosomsspb.com , the predefined name is attached to it, enterpriseregistration and the FQDN is obtained,enterpriseregistration.contosomsspb.com , which the OS is trying to resolve to IP. Accordingly, for such a DRS discovery mechanism to work, you must register in the public DNS domain of the organization A record with the name enterpriseregistration and the IP address of the pox component, for example, the WAP server.
If the password is entered correctly, the device is registered, and we return to the previous window, where you can notice that the Workplace join operation is completed.
What is going on behind the scenes? On the tablet itself, using the Certificates snap-in, you can detect the appearance of a new certificate.
It is he who will now be used as the second authentication factor when connecting to the application.
In Active Directory, the corresponding certificate object can be found in the new RegisteredDevices container . The name of the object matches the CN certificate. Attributes of this object can be viewed, for example, using ADSI Edit.
Among the attributes we will find the device name, OS type and version, the SID of the user who completed the registration, the date and time of registration, etc.
We try to connect to the portal again, get to the ADFS page again, enter the credentials of the AD account again. But now, in addition to password verification, certificate verification and access to the application have been successfully completed.
Moreover, after the first successful connection, the user receives an SSO for this application. He can close the browser, restart the machine, open the browser again, type the URL and ... access the application without any additional questions. Indeed, cookies provide the first authentication factor, and certificate the second. Naturally, not forever, and from time to time the user will have to confirm his authenticity by entering a password. But this term controls IT.
Additional Security Considerations
Let's get back to the lost / stolen tablet situation. If the device is already registered, SSO is implemented for the application, and the device fell into the wrong hands. The first line of defense is the password or PIN code to enter the device. For non-domain devices, mandatory locking can be enabled, for example, through Microsoft Intune or another MDM solution. If this has not been done? It turns out that we gave the attacker additional trump cards - he just needs to open the browser and type the URL. Obviously, in such a situation, the owner should notify his IT service as soon as possible. What will IT do then? Let's look at a few options.
If the device registration service is not used at all.
- You can restrict user account access to published applications. But what if he is on a long trip, and he needs access to the application from another device (main laptop, second tablet, etc.)?
- You can reset the user password. But it is not always obvious how this will affect access to other services.
Both solutions, as well as other options that can be offered, are quite applicable, but not ideal.
If the device has been registered.
It is enough for the administrator to find the object associated with the lost device in AD and either delete the object or set the value FALSE in its properties for the msDS-IsEnabled attribute.
Then, when connecting to the application, the device certificate will not pass verification, and the user will receive an error message. Thus, we block access to a specific device.
Well, if the user's password is compromised and became known to the attacker? Nothing will stop him from re-registering. One way to counter this scenario is to use the Microsoft Azure Multifactor Authentication (MFA) service to register your device. In this case, when registering the device, the user, in addition to entering the password, will need to pass an additional check - answer an incoming call to his mobile phone, either enter the SMS code received, or use a special application (Multi-Fator Auth), which again is in the online store Microsoft, Google and Apple.
But this is a topic for another discussion.
So, the device registration service, introduced in Windows Server 2012 R2, will help provide an additional level of security when connecting remotely to corporate applications from personal mobile devices that are not included in the AD domain and are running various OSs.
Details on installing and configuring ADFS and DRS can be found, for example, here .
Configuration features for iOS devices, creating conditional access policies, deploying WAP, etc.:
https://technet.microsoft.com/en-us/library/dn280939.aspx