User Management

Each customer/tenant with Managed OS has its own Active Directory Resource Domain, which is owned and managed by Swisscom.

In the Active Directory Resource Domain, 3 organizational unit (OU) structures are created for each business group (BG).

For each BG an OU exists for Managed Windows, Managed RHEL, and Managed SQL.
Also on the respective OU per Managed OS, several Security Groups are created for each Managed OS VM or BG, which allow different rights to be assigned to the users.

To grant privileges to a Managed OS VM, the customer can create users and groups in the Active Directory Resource Domain OU / ESCCU01 or nests user accounts from the customer Active Directory. This requires an AD trust between the customer domain and the resource domain.

These users and groups can then be added as members to the Security Groups mentioned above.

Note

Nesting via an AD trust is not supported by Managed RHEL.

Active Directory Resource Domain Layout

Each Active Directory Resource Domain has the following OU structure. OUs that are not listed below do not contain manageable AD objects by the customer.

The OU ESC_Customer contains all groups which delegates permissions to BG OUs or Active Directory
The OUs ESC_<Managed Product>-<BG IDn>-Access contain all VM and BG related groups
The customer can use the ESCCU01 for his purposes

tenant-000.sccloudres.net
|-  ESC
|    |-  ESC_Res
|        |-  ESC_Generic
|        |   |-  ESC_Customer
|        |-  ESC_Server
|            |-  ESC_MOS-LNX-<BG ID1>
|            |   |-  ESC_MOS-LNX-<BG ID1>-Access
|            |-  ESC_MOS-LNX-<BG ID2>
|            |   |-  ESC_MOS-LNX-<BG ID2>-Access
|            |   ...
|            |-  ESC_MOS-LNX-<BG IDn>
|            |   |-  ESC_MOS-LNX-<BG IDn>-Access
|            |
|            |-  ESC_MOS-SQL-<BG ID1>
|            |   |-  ESC_MOS-SQL-<BG ID1>-Access
|            |-  ESC_MOS-SQL-<BG ID2>
|            |   |-  ESC_MOS-SQL-<BG ID2>-Access
|            |   ...
|            |-  ESC_MOS-SQL-<BG IDn>
|            |   |-  ESC_MOS-SQL-<BG IDn>-Access
|            |
|            |-  ESC_MOS-WIN-<BG ID1>
|            |   |-  ESC_MOS-WIN-<BG ID1>-Access
|            |-  ESC_MOS-WIN-<BG ID2>
|            |   |-  ESC_MOS-WIN-<BG ID2>-Access
|            |   ...
|            |-  ESC_MOS-WIN-<BG IDn>
|                |-  ESC_MOS-WIN-<BG IDn>-Access
|-  ESCCU01

Mapping between Business Group Name and Business Group ID

The Business Group (BG) ID consists of 5 characters. To find out which BG has which BG ID, there are two options:

In the Active Directory Resource Domain OU /ESC/ESC_Res/ESC_Server, the OUs were created for all BGs. In the description field of each OU, the BG name can be found.
In the vRA portal, the Custom Property Scc.Ms.ResourceDomainOu exists for each Managed OS VM.
This Custom Property shows the OU name in which the privileges for this VM are managed, for example, ESC_MOS-LNX-abc12.

How to access the Active Directory Resource Domain

To order a Managed OS VM, Swisscom must provide an Active Directory Resource Domain for the tenant.

Initially, there exists the service account SA-ESCCU01-Mgmt and a role group RG_ESCCU01-Admin in the OU /ESCCU01 for accessing and managing the Active Directory Resource Domain.

A Resource Domain joined Workload is mandatory if no AD-Trust to the customer Active Directory will be implemented. It is recommended to use a Managed Windows machine.

With the program "Active Directory Users and Computers", LDAP Tools or Powershell could be the mutation privileges assigned to other users.

To allow other users managing permissions, add them to the Security Group RG_ESCCU01-Admin or one of the groups inside the ESC_Customer OU.

It is recommended to create an AD-Forest Trust. Only this allows the use of the customers user and admin accounts. It also enables the use of Kerberos.

In addition the resource domain can be accessed directly from the customer environment with the "Active Directory Users and Computers Console", PowerShell or LDAP tools. A Resource Domain joined Workload is no longer mandatory.

The delegation of resource AD permissions can be done with nesting of customers AD groups (Type Global).

Create users and groups in the Active Directory Resource Domain

In the OU /ESCCU01, the initial service account or other authorized users and groups have the rights to create users, groups and OUs.

The customer is responsible for the content of the ESCCU01 OU. Swisscom Cloud Services cannot offer identity management for customers user accounts or service accounts in the Active Directory Resource Domain.

The concept for the users, service users and groups created in the OU /ESCCU01 is in the responsibility of the customer.

Be aware that frequently used service accounts (apache, tomcat, oracle, etc.) created in the Active Directory Resource Domain can influence locally created service accounts with the same name.

Grant Active Directory mutation permission to other users

The initially created Active Directory service account has mutation rights for the security groups created in the Active Directory Resource Domain.

He can pass on these mutation rights to other users.

The mutation's permissions are granted by membership in the security groups in /ESC/ESC_Res/ESC_Generic/ESC_Customer.

The OU /ESC/ESC_Res/ESC_Generic/ESC_Customer contains the following Security Groups:

RL_ESC-Customer_ESC-MOS-LNX-<BG IDx>-Acces_GroupMgmt: Members of this group can mutate members in /ESC/ESC_Res/ESC_Server/ESC_MOS-LNX-<BG IDx>/ESC_MOS-LNX-<BG IDx>-Access
RL_ESC-Customer_ESC-MOS-SQL-<BG IDx>-Acces_GroupMgmt: Members of this group can mutate members in /ESC/ESC_Res/ESC_Server/ESC_MOS-SQL-<BG IDx>/ESC_MOS-SQL-<BG IDx>-Access
RL_ESC-Customer_ESC-MOS-WIN-<BG IDx>-Acces_GroupMgmt: Members of this group can mutate members in /ESC/ESC_Res/ESC_Server/ESC_MOS-WIN-<BG IDx>/ESC_MOS-WIN-<BG IDx>-Access
DL_Access_S_05: Members of this group have WMI Read access on every managed Windows and SQL product
RL_ESC-Customer_Domain-StagingOU_Mgmt: Management of computer objects in the /Staging OU

Security Groups per Business Group

For each Business Group there are the following OUs created in the OU /ESC/ESC_Res/ESC_Server:

ESC_MOS-LNX-<BG_ID>/ESC_MOS-LNX-<BG_ID>-Access
ESC_MOS-SQL-<BG_ID>/ESC_MOS-SQL-<BG_ID>-Access
ESC_MOS-WIN-<BG_ID>/ESC_MOS-WIN-<BG_ID>-Access

Depending on the Managed Service, i.e. Managed RHEL (OU with Linux), Managed SQL (OU with SQL) or Managed Windows (OU with Windows), several Security Groups are created in the corresponding OU.

The number of security groups depends on the Managed Service.

Each security group has specific rights associated which are defined below for each Managed OS.

In each OU, security groups exist to assign the rights to all VMs of the Managed OS of a BG.
These security groups have the following naming scheme:
DL_ESC-MOS-LNX-<BG_ID>-Access_S_<00-99>

In addition, the security groups are created for each VM.
These security groups have the following naming scheme:
DL_ESC-MOS-LNX-Access_<hostname>_S<00-99>

This allows the user to obtain the rights for all Managed OS VMs in a business group, or dedicated for specific VMs.

Members of the corresponding security groups receive the privileges associated with the respective security group.

Security Groups for Managed Windows

In the OU /ESC/ESC_Res/ESC_Server/ESC_MOS-WIN-<BG IDx>/ESC_MOS-WIN-<BG IDx>-Access are 5 Security Groups created for each VM of the business group. The following privileges are granted through these Security Groups:

Security Group Name	Granted Permissions
`DL_ESC-MOS-WIN-Access_<hostname>_S_01`	Allow Remote Desktop
`DL_ESC-MOS-WIN-Access_<hostname>_S_02`	Allow Run As Batch
`DL_ESC-MOS-WIN-Access_<hostname>_S_03`	Allow Logon as Service
`DL_ESC-MOS-WIN-Access_<hostname>_S_04`	Allow local Admin
`DL_ESC-MOS-WIN-Access_<hostname>_S_05`	Allow WMI Read

Security Groups for Managed RHEL

In the OU /ESC/ESC_Res/ESC_Server/ESC_MOS-LNX-<BG IDx>/ESC_MOS-LNX-<BG IDx>-Access are 4 Security Groups created for each VM of the business group. The following privileges are granted through these Security Groups:

Security Group Name	Granted Permissions
`DL_ESC-MOS-LNX-Access_<hostname>_S_01`	Allow ssh access to the system. Necessary for all customer users which should be able to login to the Managed RHEL VM
`DL_ESC-MOS-LNX-Access_<hostname>_S_02`	Allow privileged views to logfiles, repositories, disks, firewalls, etc. Allow the usage of following commands via sudo: `/bin/cat`, `/bin/grep`, `/bin/head`, `/bin/less`, `/bin/ls`, `/bin/more`, `/bin/tail`, `/bin/journalctl`, `/bin/yum repolist`, `/sbin/pvs`, `/sbin/vgs`, `/sbin/lvs`, `/sbin/iptables -L`, `/sbin/iptables -L -v`, `/sbin/iptables -L -n`, `/sbin/iptables -L -n -v`
`DL_ESC-MOS-LNX-Access_<hostname>_S_03`	Allow privileged stop/start/restart commands. Allow the usage of following commands via sudo: `/bin/systemctl stop .service`, `/bin/systemctl start .service`, `/bin/systemctl restart *.service` But prohibit the stop/start for services that are managed by the Managed OS operation team
`DL_ESC-MOS-LNX-Access_<hostname>_S_04`	Allows high privileged access - BUT only when the VM is in the Temp Admin state Allow the usage of all commands via sudo

Security Groups for Managed SQL

In the OU /ESC/ESC_Res/ESC_Server/ESC_MOS-SQL-<BG IDx>/ESC_MOS-SQL-<BG IDx>-Access are 2 Security Groups created for each VM of the business group.
The following privileges are granted through these Security Groups:

Security Group Name	Granted Permissions
`DL_ESC-MOS-SQL-Access_<hostname>_S_05`	Allow WMI Read
`DL_ESC-MOS-SQL-Access_<hostname>_S_11`	Allow Act on Behalf of

User Management restrictions for Managed Windows

Please consider the following restrictions for Managed Windows:

Customer user accounts must be configured in the customer Active Directory domain.
Local accounts must not be member of the local Administrators of a Managed OS VM.
Local service accounts are not allowed.
Service accounts can be created in the resource domain or in the accounting domain.
Interactive login with a service account is prevented.

Swisscom uses the compliance checks to check the membership and permission of local Administrator and application users.
Consult the Technical Description for more information about the compliance check.

All permissions for accessing a Managed Windows VM are assigned through groups in the resource domain.
The following permissions are necessary:

Permissions for Remote Desktop Login
Read Permissions for Remote WMI

User Management restrictions for Managed RHEL

Please consider the following restrictions for Managed RHEL:

The users to be used for Managed RHEL must exist in the OU /ESCCU01!
It is not possible to use users via AD trust because the AD trust does not provide the required Unix attributes for the user.
Local users are allowed as long as they have no root permissions granted.
Local service accounts are allowed as long as they have no root permissions granted. But be aware that frequently used service accounts (apache, tomcat, oracle, etc.) created in the AD can influence locally created service accounts with the same name.
Local users must have an UID < 99'999'999 and a GID < 99'999'999, as the higher values are used for the AD users
VMs which were provisioned before the Active Directory Resource Domain user concept was introduced the ssh restriction is not applied (no AllowGroups restrictions in /etc/ssh/sshd_config).

For all users which are created within the OU /ESCCU01 a scheduled task will define the AD attributes which are necessary for accessing Linux based workload. It is not allowed to define or change the uid and gidnumber attribute by yourself. If the attributes are changed they are reset by the scheduled task. The following attributes will be defined with the schedules task:

AD Attribute	Description
uid	User ID (will be set automatically)
msSFU30Name	User Name
gidnumber	Group ID
loginShell	Login Shell
msSFU30NisDomain	NIS Domain
unixHomeDirectory	Home Directory

Swisscom uses the compliance checks to check the membership and permission of local accounts.
Consult the Technical Description for more information about the compliance check.

Local groups to allow local users for ssh

With the introduction of the Active Directory Resource Domain user concept for Managed RHEL it's initially no longer possible to do a ssh login with a local user. To allow ssh login for local users they need to be added to the local group local-ssh-user

$ sudo groupadd -g 8888 local-ssh-user
$ sudo usermod -a -G local-ssh-user <your_local_user>

Create local users if they already exists in the Active Directory Resource Domain

If a local user cannot be created with the useradd command with the error message User already exists, then the user may already exist in the Active Directory resource domain. In this case, the command luseradd must be used.

$ sudo useradd <username>
useradd: user '<username>' already exists
$ sudo luseradd <username>

Change a user password in the Active Directory from a Managed RHEL VM

It is possible to change the password for an Active Directory user on a Managed RHEL VM. The smbpasswd command is necessary from the samba-common-tools RPM.

$ sudo yum install -y samba-common-tools
$ smbpasswd -r <domain>

Managed RHEL VMs that already existed at the time of the introduction of the Active Directory Resource Domain user concept, did not receive any ssh restrictions afterwards, so that existing applications are not affected. If the ssh restriction for older VMs is still desired, this must be ordered with a service request from the Managed RHEL operation team. With the following command you can check if the ssh restriction is enabled:

$ sudo grep AllowGroups /etc/ssh/sshd_config

If the AllowGroups parameter does not exist in the /etc/ssh/sshd_config or if the parameter allows all groups *, then the ssh restriction is not enabled.

# User Management

Note

# Active Directory Resource Domain Layout

# Mapping between Business Group Name and Business Group ID

# How to access the Active Directory Resource Domain

# Create users and groups in the Active Directory Resource Domain

# Grant Active Directory mutation permission to other users

# Security Groups per Business Group

# Security Groups for Managed Windows

# Security Groups for Managed RHEL

# Security Groups for Managed SQL

# User Management restrictions for Managed Windows

# User Management restrictions for Managed RHEL

# Local groups to allow local users for ssh

# Create local users if they already exists in the Active Directory Resource Domain

# Change a user password in the Active Directory from a Managed RHEL VM

# Enable ssh login restriction for older Managed RHEL VMs