Your SAP on Azure – Part 8 – Single Sign-On using Azure AD Domain Services

[BJarkowski]

Almost two years ago, when I started my journey with Microsoft Azure, I wrote a short blog about implementing the Single Sign-On for SAP Fiori using Azure Active Directory. The solution is very easy to implement and use, but the scope was limited to web-based applications. I was surprised that the on-premise domain services didn’t have its counterpart in the Azure platform and to use features like Kerberos-based authentication we still had to follow the old route – create VM and manually configure (and maintain!) required services.

But the list of available features is rapidly growing. What I like the most about Microsoft Azure is the constant innovation. Things that were not possible yesterday are working well now. A quick look at the Azure Updates website is enough to understand how much effort Microsoft makes to release new features – every two or three days there is another announcement. And in November 2017 Microsoft shared an important update, that in my opinion will highly influence how IT landscapes will look in the future.

I’m pretty sure you have an idea already which service I’m going to describe in this post. It’s the Azure Active Directory Domain Services, a cloud implementation of the very popular feature that so far was only available as a part of Windows Server. I would like to present you a basic configuration of the managed domain and how to use it to enable the Kerberos authentication with your SAP system.

DEPLOY AZURE ACTIVE DIRECTORY DOMAIN SERVICES

Although the main purpose of this blog is to present the Kerberos Single Sign-On configuration I would also like to quickly go through the basic steps required to provision the Azure AD Domain Services. It will help you to better understand how the service works and what are the differences comparing to the on-premise version.

Log in to the Azure portal, select Azure AD Domain Services and click Add. The first step is to define the DNS domain name – the field automatically populated with the domain name of your Azure AD.



In the second step choose a virtual network that you’d like to use to deploy the service. The Azure AD DS is automatically synchronizing with the Active Directory associated with the chosen network. To increase security a separate subnet is required. Even if you don’t specify a Network Security Group it will automatically get created.



The third step allows you to assign users to the DC Administrator roles – it will let them perform basic administrative tasks in the managed domain, like creating new objects and joining computers. When the computer joins a domain all users with DC Administrator role will get local admin privileges.



Confirm changes on the summary page. It’s worth to notice that the domain stores password hashes exactly as it’s done currently on-premise.



The deployment can take up to an hour and it is followed by the initial user replication which can take some time as well. In my case the total required time was around 2 hours, however, my Azure AD did not have a lot of users – in case of large deployments it can take much longer.



To use the Kerberos single sign-on it is required to follow the procedure to generate the password hashes. My domain consists only of cloud users, therefore, the process is simple and requires changing the password which after 20-30 minutes is synchronized to the domain. Afterward, you can use the admin account to join the computer to the domain:



Currently, the Azure Portal allows only basic capabilities to perform administrative tasks for the domain like managing users and groups. To be able to use make advanced configuration, it is required to install the AD Management Tools on one of the servers.



All changes done through Active Directory Administrative Center are not replicated back to Azure AD, therefore it should be carefully used when creating new users and managing group assignment.

(source: Microsoft.com)

The Kerberos authentication requires a service user – but as we don’t have a real user behind it we can create it directly in Active Directory Domain Services. To keep him separated from the rest of the domain I have created a new Organizational Unit.



The user creation is straightforward and looks exactly as in on-premise deployments.



The service user requires to have a special attribute servicePrincipalName with the value SAP/<SID>:



SAP NETWEAVER CONFIGURATION

When the basic domain settings are completed we can jump to NetWeaver configuration. I recommend using transaction SNCWIZARD that sets up the profile parameters and create initial PSE that secures the communication channel between the client and the SAP server.



Depending on our current setup it may be required to implement additional profile parameters:



The Server Instance Status shows the summary of the SNC status. We can skip X.509 credentials as we want to use Kerberos Single Sign-On.

Restart your application server that new parameters are set correctly. Then open transaction SPNEGO to fill the details about service user.



Last configuration step is to assign the SNC name to the user. You can do it in SU01 or through mass maintenance.



Before we can verify the solution we just need to enable SNC in SAP GUI. Select Activate Secure Network Communication on the Network tab and type the SNC Name – it’s the same value that was generated in SNCWIZARD (and can be taken from STRUST):



The SAP Single Sign-On configuration is completed. We can try to log in:



Success! It worked! I was able to log in to the system without the need to remember username or password!