Tablet and domain: unity and struggle of opposites
Let's imagine a fairly common scenario for today. A number of business applications are deployed in the corporate network. These applications are published for access from outside 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 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 fundamentals and architecture of DRS. Details of the settings can be found in the fourth module of the course “ Corporate devices. How to manage hybrid credentials . ”
Inside the corporate network there is a HTTPS access web application published for connecting outside. From any platform from any browser connected, 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. Anything that is convenient to carry around with you can easily be lost or stolen. Any new "owner" of the device curiosity for the sake of or on malicious intent may try to "study" URLs in the history of the browser. And with the saved cookies, which are probably used on personal devices, it will not be difficult to get access to the organization’s applications.
')
In a domain network by means of group policies, such situations are easily avoided. Starting with the password for the login to the domain device, ending with certificates for authentication when accessing the application. How to deal with devices that can not be included in the domain? 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 surely by IT staff, and each new device generates a corresponding chain of actions. And I want the owner of the device to cope with such a task, and then, when it really becomes necessary.
One solution is to use DRS from Windows Server 2012 R2.
As the service name suggests, DRS implements the device registration procedure. During the registration process, DRS generates an X.509 certificate that is downloaded to the device, and also creates a new object in Active Directory containing information about both the device and the user who performed the registration.
Every time a user connects from a registered device to an application, the user is authenticated (either he enters a password or uses a cookie) and the certificate is checked. 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, the DRS service is installed with ADFS. ADFS, as seen in the figures above, plays a key role in the authentication process. To use the registration service for the application, you must configure ADFS authentication. 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. The role of the proxy can be performed by the Web Application Proxy (WAP) - a new Windows Server 2012 R2 service. ADFS, in turn, authenticates the user and, if device registration is configured, verifies the certificate. If authentication is successful, ADFS generates a token of access for the requested application and returns the token to the browser on the user device. Then the user gets access to the application.
If we talk about infrastructure requirements, then to use DRS, you need to expand the AD scheme and have at least one server with Windows Server 2012 R2 and the elevated ADFS role.
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 be the corporate application. In my infrastructure, ADFS is configured in such a way that device registration is required only if the device is located outside the corporate network. If the tablet is connected, for example, to corporate Wi-Fi, then authentication by user login and password is sufficient. And, of course, nothing is required of the user at all if he accesses the application from a domain computer in the corporate network. There is a full Single Sign-On. The ability to configure such access conditions (conditional access), and for a particular application, is another serious advantage of using ADFS for the scenario in question. How conditional access policies are set can be found in the fourth module of the course “ Corporate devices. How to manage hybrid credentials . ”
So, an employee of the company is outside the company and in the browser of a tablet that is not included in the domain, types the URL of the corporate portal SharePoint. Request via WAP is redirected to ADFS, and we see this picture.
As you can see, the elements of the ADFS authentication page, as well as the error message pages (image, logo, message text), are configured. The user specifies the login and password of his domain account, and the login is entered in the User Principal Name (UPN) format. 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 take to register the tablet. These actions are different for different platforms. So for iOS, you just need to go to the URL: https: // <name of the adfs server> / 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 , it is docked with the predefined name, enterpriseregistration, and the FQDN is obtained, enterpriseregistration.contosomsspb.com , which the OS tries to resolve to IP. Accordingly, in order for such a DRS detection mechanism to work, it is necessary to register in the public DNS domain of the A record organization with the name enterpriseregistration and the IP address of the poroxy component, for example, a WAP server.
If the password is entered correctly, the device is registered, and we return to the previous window, where you can see that the Workplace join operation is completed.
What happens behind the scenes? On the tablet itself, using the Certificates snap-in, you can detect the appearance of a new certificate.
That it will now be used as the second factor of authentication when connecting to the application.
In Active Directory, the object corresponding to the certificate can be found in the new RegisteredDevices container. The name of the object is the same as the CN of the certificate. The attributes of this object can be viewed, for example, using ADSI Edit.
Among the attributes we find the device name, the type and version of the OS, the SID of the user who performed 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, besides checking the password, the certificate verification is successfully completed, and the application has been granted access.
Moreover, after the first successful connection, the user receives SSO for this application. He can close the browser, restart the machine, open the browser again, type the URL and ... get access to the application without any additional questions. Indeed, cookies provide the first authentication factor, certificate - the second. Naturally, not forever, and periodically the user will have to confirm their authenticity by entering a password. But this term is controlled by IT.
Let's go back to the situation with the loss / theft of the tablet. 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? So, we gave the attacker additional trumps - he just needs to open the browser and type the URL. Obviously, in such a situation, the owner must notify his IT service as soon as possible. What will IT do then? Let's look at several 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 perfect.
If the device has been registered.
It is enough for the administrator to find in AD the object associated with the lost device and either delete the object, or set the value for the msDS-IsEnabled attribute to FALSE in its properties.
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 password is compromised and became known to the attacker? Nothing prevents him from re-registering. One option to counter this scenario is to use Microsoft Azure Multifactor Authentication Service (MFA) to register the device. In this case, when registering a device, the user, in addition to entering a password, will have to undergo an additional check - to answer an incoming call on his mobile phone, or enter a code received via SMS, or use a special application (Multi-Fator Auth), which is again in the online store Microsoft, Google and Apple.
But this is a topic for another conversation.
So, the device registration service, which appeared in Windows Server 2012 R2, will help provide an additional level of security when remotely connecting to corporate applications from personal mobile devices that are not included in the AD domain and are running different operating systems.
Details on installing and configuring ADFS and DRS can be found, for example, here .
Features settings for iOS devices, the creation of conditional access policies, the deployment of WAP, etc .:
https://technet.microsoft.com/en-us/library/dn280939.aspx
In this article, I will focus on the fundamentals and architecture of DRS. Details of the settings 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 HTTPS access web application published for connecting outside. From any platform from any browser connected, 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. Anything that is convenient to carry around with you can easily be lost or stolen. Any new "owner" of the device curiosity for the sake of or on malicious intent may try to "study" URLs in the history of the browser. And with the saved cookies, which are probably used on personal devices, it will not be difficult to get access to the organization’s applications.
')
In a domain network by means of group policies, such situations are easily avoided. Starting with the password for the login to the domain device, ending with certificates for authentication when accessing the application. How to deal with devices that can not be included in the domain? 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 surely by IT staff, and each new device generates a corresponding chain of actions. And I want the owner of the device to cope with such a task, and then, when it really becomes necessary.
One solution is to use DRS from Windows Server 2012 R2.
What is the main idea?
As the service name suggests, DRS implements the device registration procedure. During the registration process, DRS generates an X.509 certificate that is downloaded to the device, and also creates a new object in Active Directory containing information about both the device and the user who performed the registration.
Every time a user connects from a registered device to an application, the user is authenticated (either he enters a password or uses a cookie) and the certificate is checked. 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 pre-configuration of the device by an IT professional.
- DRS supports various platforms:
- Windows 8.1 and above
- iOS 6 and up
- Android - Samsung KNOX
- Windows 7 Pro (included in the domain)
- DRS does not require PKI deployment
What does this look like?
In Windows Server 2012 R2, the DRS service is installed with ADFS. ADFS, as seen in the figures above, plays a key role in the authentication process. To use the registration service for the application, you must configure ADFS authentication. 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. The role of the proxy can be performed by the Web Application Proxy (WAP) - a new Windows Server 2012 R2 service. ADFS, in turn, authenticates the user and, if device registration is configured, verifies the certificate. If authentication is successful, ADFS generates a token of access for the requested application and returns the token to the browser on the user device. Then the user gets access to the application.
If we talk about infrastructure requirements, then to use DRS, you need to expand the AD scheme and have at least one server with Windows Server 2012 R2 and the elevated ADFS role.
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 be the corporate application. In my infrastructure, ADFS is configured in such a way that device registration is required only if the device is located outside the corporate network. If the tablet is connected, for example, to corporate Wi-Fi, then authentication by user login and password is sufficient. And, of course, nothing is required of the user at all if he accesses the application from a domain computer in the corporate network. There is a full Single Sign-On. The ability to configure such access conditions (conditional access), and for a particular application, is another serious advantage of using ADFS for the scenario in question. How conditional access policies are set can be found in the fourth module of the course “ Corporate devices. How to manage hybrid credentials . ”
So, an employee of the company is outside the company and in the browser of a tablet that is not included in the domain, types the URL of the corporate portal SharePoint. Request via WAP is redirected to ADFS, and we see this picture.
As you can see, the elements of the ADFS authentication page, as well as the error message pages (image, logo, message text), are configured. The user specifies the login and password of his domain account, and the login is entered in the User Principal Name (UPN) format. 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 take to register the tablet. These actions are different for different platforms. So for iOS, you just need to go to the URL: https: // <name of the adfs server> / 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 , it is docked with the predefined name, enterpriseregistration, and the FQDN is obtained, enterpriseregistration.contosomsspb.com , which the OS tries to resolve to IP. Accordingly, in order for such a DRS detection mechanism to work, it is necessary to register in the public DNS domain of the A record organization with the name enterpriseregistration and the IP address of the poroxy component, for example, a WAP server.
If the password is entered correctly, the device is registered, and we return to the previous window, where you can see that the Workplace join operation is completed.
What happens behind the scenes? On the tablet itself, using the Certificates snap-in, you can detect the appearance of a new certificate.
That it will now be used as the second factor of authentication when connecting to the application.
In Active Directory, the object corresponding to the certificate can be found in the new RegisteredDevices container. The name of the object is the same as the CN of the certificate. The attributes of this object can be viewed, for example, using ADSI Edit.
Among the attributes we find the device name, the type and version of the OS, the SID of the user who performed 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, besides checking the password, the certificate verification is successfully completed, and the application has been granted access.
Moreover, after the first successful connection, the user receives SSO for this application. He can close the browser, restart the machine, open the browser again, type the URL and ... get access to the application without any additional questions. Indeed, cookies provide the first authentication factor, certificate - the second. Naturally, not forever, and periodically the user will have to confirm their authenticity by entering a password. But this term is controlled by IT.
Additional Security Considerations
Let's go back to the situation with the loss / theft of the tablet. 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? So, we gave the attacker additional trumps - he just needs to open the browser and type the URL. Obviously, in such a situation, the owner must notify his IT service as soon as possible. What will IT do then? Let's look at several options.
If the device registration service is not used at all.
- You can deny 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 perfect.
If the device has been registered.
It is enough for the administrator to find in AD the object associated with the lost device and either delete the object, or set the value for the msDS-IsEnabled attribute to FALSE in its properties.
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 password is compromised and became known to the attacker? Nothing prevents him from re-registering. One option to counter this scenario is to use Microsoft Azure Multifactor Authentication Service (MFA) to register the device. In this case, when registering a device, the user, in addition to entering a password, will have to undergo an additional check - to answer an incoming call on his mobile phone, or enter a code received via SMS, or use a special application (Multi-Fator Auth), which is again in the online store Microsoft, Google and Apple.
But this is a topic for another conversation.
So, the device registration service, which appeared in Windows Server 2012 R2, will help provide an additional level of security when remotely connecting to corporate applications from personal mobile devices that are not included in the AD domain and are running different operating systems.
Details on installing and configuring ADFS and DRS can be found, for example, here .
Features settings for iOS devices, the creation of conditional access policies, the deployment of WAP, etc .:
https://technet.microsoft.com/en-us/library/dn280939.aspx
Source: https://habr.com/ru/post/255955/
All Articles