AWS for SAP

How to integrate HAQM WorkSpaces with SAP Single Sign-On

SAP Single Sign-On allows users to have secure access to SAP and non-SAP systems using centralized authentication whether the systems are on-premises or in the cloud. SAP Single Sign-On provides the simplicity to manage users’ authentication, secure data communication, and integrate with two-factor and risk-based authentication. This includes possession of mobile phone and RSA SecurID card. Moreover, SAP Single Sign-On supports different types of authentication methods including Kerberos/SPNEGO, X.509 certificates and Security Assertion Markup Language (SAML). In this blog, we share how to integrate SAP Single Sign-On(*) based on Kerberos/SPNEGO with HAQM WorkSpaces. We also cover how to use your existing Active Directory service, either in the public cloud or an on-premises environment, to quickly provide thousands of desktops to workers across the globe.

(*)Based on the SAP Note 1848999, licenses for SAP Single Sign-On are required. Please contact your SAP account executive for more detail.

In general, there are three scenarios:

  1. Integrate HAQM WorkSpaces with AD Connector and existing Active Directory on-premises environment (figure 1)
  2. Integrate HAQM WorkSapces with Azure Active Directory Domain Services (Azure AD-DS) (figure 2)
  3. Integrate HAQM WorkSpaces with AD Connector, pre-built Active Directory (AD) in HAQM Elastic Compute Cloud (HAQM EC2), and AWS Directory Service for Microsoft Active Directory (AWS Managed Microsoft AD) (figures 3-1 and 3-2)

In this blog, we will be sharing an example of scenario three using AWS Managed Microsoft AD.

You can apply scenario one using the process outlined in the blog “How to Connect Your On-Premises Active Directory to AWS Using AD Connector.” Scenario two can be referenced in the blog “Add your WorkSpaces to Azure AD using Azure Active Directory Domain Services.

Follow SAP Note 66971 to ensure the supportability on the selected Windows version with SAP GUI. In this blog, we demonstrate the GUI installation on Windows 10.

Scenario 1 architecture – HAQM WorkSpaces and AD Connector with AD on-premisesHAQM WorkSpaces and AD Connector with AD on-premise

Figure 1 HAQM WorkSpaces and AD Connector with AD on-premises

Scenario 2 architecture – HAQM WorkSpaces and Azure AD-DS

HAQM WorkSpaces and Azure AD-DS

Figure 2 HAQM WorkSpaces and Azure AD-DS

Scenario 3 architecture1 – HAQM WorkSpaces and AD Connector with AD built in HAQM EC2

HAQM WorkSpaces and AD Connector with AD built in HAQM EC2

Figure 3-1 HAQM WorkSpaces and AD Connector with AD built in HAQM EC2

Scenario 3 architecture2 – HAQM WorkSpaces and AWS Managed Microsoft AD

HAQM WorkSpaces and AWS Managed Microsoft AD

Figure 3-2 HAQM WorkSpaces and AWS Managed Microsoft AD

Prerequisites:

  • You already have an AWS account and a default HAQM Virtual Private Cloud (VPC).
  • You deploy HAQM WorkSpaces and AWS Managed Microsoft AD in a public subnet.
  • You can access HAQM WorkSpaces with a public internet.
  • You have an existing SAP license for SAP Single Sign-On.
  • You can deploy HAQM WorkSpaces in an available Region.

Deployment Steps:

  1. Setup AWS Managed Microsoft AD.
  2. Launch HAQM WorkSpaces with selected created users from AWS Managed Microsoft AD.
  3. Install SAP GUI and SAP Secure Login Client on the launched HAQM WorkSpaces.
  4. Configure the SAP GUI single sign-on (SSO) feature accordingly.
  5. Test the SAP GUI SSO feature.
  6. (Optional) Build up HAQM WorkSpaces image and bundles for scale-out usage and centralize the SAP GUI logon entry in a shared Windows file system.
  7. (Alternative) Deploy HAQM AppStream2.0 with SAP GUI single sign-on.

Walkthrough:

Setup AWS Managed Microsoft AD and deploy HAQM WorkSpaces

Download the sample code here to deploy AWS Managed Microsoft AD and HAQM WorkSpaces.

Requirements:

Overview:

There are two CDK stacks in app.py file:

  • AWSManagedAD:
    • Create AWS Managed Microsoft AD.
    • Create an HAQM Route 53 private hosted zone and an A record pointing to AWS Managed Microsoft AD.
    • Create an HAQM EC2 Windows instance for domain user/group management.
    • Create an AWS Systems Manager Parameter and Document that attaches to the HAQM EC2 instance to join AWS Managed Microsoft AD automatically.
    • Create an AWS Lambda function to register HAQM WorkSpaces with AWS Managed Microsoft AD.
  • AWSWorkSpaces:
    • Create an HAQM WorkSpaces for SAP GUI configuration

Setup process:

  1. Clone my sample Github repo to your folder in your device and navigate into the folder.
  2. Create two AWS Secrets Managers secrets. One is the secret for domain admin password, and the other is the pre-created HAQM EC2 key pair name. The name of the Secret Key is “Key”. The password should comply with the AWS Managed Microsoft AD password rule.
    The image shows the password for AWS Managed Microsoft AD admin user. The value is stored in AWS Secrets Manager. The image shows the HAQM EC2 key pair name. The value is stored in AWS Secrets Manager.
  3. Edit cdk.json file to meet your environment
    	{  
    	  "app": "python3 app.py",  
    	  "context": {  
    	      "Account": "<AWS Account ID>",  
    	      "Region": "<AWS Region>",  
    	      "Domain_name": "<AD Domain Name>",  
    	      "Secret_domain_password_arn": "<Secret Manager for AD Password ARN value>",  
    	      "Instance_type": "<EC2 Instance Type>",  
    	      "VpcId": "<VPC ID>",  
    	      "Subnet1": [ "<Piublic Subnet1 ID>", "<The AZ that the Subnet1 locates>" ],  
    	      "Subnet2": [ "<Piublic Subnet2 ID>", "<The AZ that the Subnet2 locates>" ],  
    	      "Secret_keypair_arn": "< Secret Manager for EC2 Key Value ARN value >",  
    	      "WorkSpacesUser" : "<NetBIos\User>",  
    	      "WorkSpacesBundle": "wsb-8vbljg4r6"  
    	  }  
    	}  
    

    Parameters:

    Region: Choose the Region that supports the AWS Directory Service and HAQM WorkSpaces. In this blog, I use the Region in us-west-2.
    Domain_name: Fill in the preferred domain name for AWS Managed Microsoft AD. I use test.lab in this blog.
    Secret_domain_password_arn: Input the secret HAQM Resource Name (ARN) value for domain admin password secret.
    Instance_type: Refer to the HAQM EC2 Documentation for the instance type.
    Subnet[1|2]: Fill in the list value for the two subnets in the same VpcId. The former element in the array is the subnet ID, and the latter is the Availability Zone where the subnet resides.
    Secret_keypair_arn: Input Secret ARN value for the HAQM EC2 key pair secret.
    WorkSpacesUser: Fill in the user name that you would create after the AWS Managed Microsoft AD is built. The format is NETBIOS\AD_USER.
    WorkSpacesBundle: Fill in the default HAQM WorkSpaces bundle ID to deploy SAP GUI. I picked up wsb-8vbljg4r6, which is for Standard Windows 10.

  4. Install the Python required libraries for cdk.
    $ pip install -r requirement.txt
  5. Run the CDK bootstrap on your AWS account.
    $ cdk bootstrap  aws://<AWS_ACCOUNT>/<AWS_REGION>
  6. Deploy the AWSManagedAD stack with your AWS profile.
    $ cdk deploy AWSManagedAD --profile <AWS Profile>
    If you don’t specify your AWS profile, the default profile will be used. This stack might take 10-20 minutes to deploy all resources.
  7. Once the AWSManagedAD stack is deployed, you can log into the HAQM EC2 instance and create a domain user for HAQM WorkSpaces later. Revise the default security group to connect from your local environment to your HAQM EC2 instance. Please specify First Name, Last Name and the Email for the user.
  8. Deploy the AWSWorkSpaces stack with a specified domain user.
    $ cdk deploy AWSWorkSpaces --profile <AWS Profile>
    This stack might take 10 minutes to deploy HAQM WorkSpaces.
  9. Once the HAQM WorkSpaces is built, you can download and install HAQM WorkSpaces Client, fill in the registration code from the HAQM WorkSpaces console and log in with domain user.
    The image shows login page for HAQM WorkSpaces client.

Configure SAP GUI single sign-on feature accordingly

Requirements:

  • The SAP GUI and SAP Secure Login Client are installed in HAQM WorkSpaces.
  • Log into HAQM WorkSpaces with the specified domain user.
  • The network connection from HAQM WorkSpaces to the SAP Systems is allowed.
  • SAP Systems are installed on your own.

Steps:

  1. Use the Tcode SNCWIZARD to set up the Secure Network Communications (SNC) identity and change the SAP profile parameters accordingly.
  2. Create a domain user for SSO. In this sample, the user is “Hank”. Update the service attribute ServicePrincipalName in “Attribute Editor.”
    The image shows the step to set up ServicePrincipalName property for Windows domain user.
  3. Create a Kerberos User in Tcode SNCWIZARD to match the domain user. Ensure the user principal is in GREEN LIGHT.
    The image shows the first step in SAP T-code SNCWIZARD.The image shows the SPNego configuration result for a domain user.
  4. Copy the SNC name to map to the NetWeaver User in Tcode SU01.
    The image shows the User Mapping value for domain userThe image shows how to fill in SNC name to map SAP GUI users in T-code SU01.
  5. Complete the remainder of the process in SNCWIZARD.
    The image shows the final step in SAP T-code SNCWIZARD.The image shows the final step in SAP T-code SNCWIZARD.

Test the SAP GUI SSO feature

  1. Activate the Secure Network Communication option in the SAP GUI and input CN name.
    The image shows configuration for SAP GUI logon entry.
  2. Double-click the designated SAP System to check whether the single sign-on function is ready.
    The image shows success for SAP GUI single sign-on result.

 

 

 

(Optional) Build up HAQM WorkSpaces image and bundles for scale-out usage and centralize the SAP GUI logon entry in a shared Windows file system.

You might have many staff members that need access to SAP systems with the SAP GUI. In a traditional environment, each user must install the SAP GUI on their laptops and set up SAP logon entries repeatedly. With HAQM WorkSpaces, you can easily duplicate pre-built bundles and provision the environment to each user in a few clicks following the document.

Next, you can create a bundle to deploy a pre-built laptop for each user. Each user must maintain the SAP GUI logon entry in a repeated effort.  They can use a share file system (either with HAQM FSx Windows file systems or a self-built Windows file systems) to adopt a centralized SAP logon entry for different department users, reducing overall efforts. Moreover, you can deploy SAP GUI Installation Server to push customized Windows scripts to users. The detailed process is in the SAPGUI Installation Server Part 5 – Scripting blog.

The following process shows two HAQM WorkSpaces sharing the same HAQM FSx file system for SAP GUI logon entry.

Requirements:

  • An HAQM FSx file system is created in the same domain with HAQM WorkSpaces and mapped in a network device in the first HAQM WorkSpaces.
  • The domain users are in the same organization and have permission to access the HAQM FSx file system.
  • Set up proper security croup and Network ACLs (NACL) between HAQM WorkSpaces and the HAQM FSx file system.

(HAQM WorkSpaces1)

  1. The pre-configured SAP GUI and the SAPGUILandscape.xml(SAP Logon entry) is changed to the share folder Z:\
    The image shows SAP logon entry configuration file in first HAQM WorkSpaces.

    (HAQM WorkSpaces2)
  2. Build another HAQM WorkSpaces, connect to the same share folders, and change the SAP GUI option (Server Configuration Files) to the same SAPGUILandscape.xml.
    The image shows SAP logon entry configuration file can be read in first HAQM WorkSpaces.
    (HAQM WorkSpaces2)
  3. After you restart the SAP GUI, the system lists are ready.
    The image shows the result that second HAQM WorkSpaces imported the shared SAP GUI logon entry.

Last, since SAP SNC is mapped one-to-one from the domain user to the SAP GUI user, you need to pre-map different domain users to the related SAP GUI users. The other HAQM WorkSpaces users from domain can use SSO to the SAP systems.

(Alternative) Deploy HAQM AppStream2.0 with SAP GUI SSO

HAQM AppStream 2.0 is a fully managed application streaming service that provides your users secure access to your SAP environment through a browser on any computer, including PCs, Chromebooks, and Macs.

There are several differences in configuring HAQM AppStream 2.0 with HAQM WorkSpaces:

  • HAQM AppStream 2.0 use Directory Configs rather than AWS Directory Service. You should pre-configure Directory Configs and ensure the Image Builder of HAQM AppStream 2.0 can connect to domain in the starting stage. (You can replace the Dynamic Host Configuration Protocol (DHCP) option set in the VPC to the new option with custom Domain Name System (DNS)).
  • Once the HAQM AppStream 2.0 Image Builder is ready, and the configuration for SAP GUI SSO in the image is done, create a related fleet and associate it to a stack.
  • HAQM AppStream 2.0 is a browser-based service, so the authentication is verified by a SAML 2.0 identity provider from Windows domain. You can refer to the AWS blog How to Enable Server-Side LDAPS for Your AWS Microsoft AD Directory to set up Active Directory Federation Services (ADFS) in your environment and Enabling Identity Federation with AD FS 3.0 and HAQM AppStream 2.0 to connect HAQM AppStream 2.0 to the stack.

The test environment is below.

HAQM AppStream 2.0 with AWS Managed Microsoft AD

  1. Configure the HAQM AppStream 2.0 directory config.
    The image shows the Directory Configs in HAQM Appstream 2.0.
  2. Create an HAQM AppStream 2.0 image.
    The image shows the HAQM Appstream 2.0 Image Assistant.The image shows the creation of HAQM Appstream 2.0 Image.
  3. Create a federation rule in the ADFS
    The image shows the SAML configuration in ADFS.
  4. The HAQM AppStream 2.0 with SAP GUI SSO result is below
    The image shows success for SAP GUI single sign-on result from HAQM Appstream 2.0 URL.

 

 

 

 

 

You can refer Deploying SAP GUI on HAQM AppStream 2.0 guide for detailed steps.

Extension

In order to extend the usage of HAQM WorkSapces for disaster recovery in different AWS Regions, you can build HAQM WorkSpaces in multiple Regions to replicate configuration by referring to the AWS blog Building a multi-region disaster recovery environment for HAQM WorkSpaces.

Conclusion

Using HAQM Workspaces to integrate SAP GUI SSO features is flexible and scalable for the SAP users around the world. Besides being an easy way to deploy the HAQM WorkSpaces, you can reduce the capital costs to move your Windows desktops to HAQM WorkSpaces.