User Management

Each ESC tenant with Managed RHEL VMs 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 service. Also, on the respective OU, several security groups are created for each managed VM or BG, which allow different privileges to be assigned to the users.

To grant privileges to a managed 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 the Managed RHEL service.

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 ESSCU01 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 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 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 VM.

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 administration 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 permission 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 permission for the security groups created in the Active Directory resource domain.

He can pass on these mutation permission 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 service, e.g. Managed RHEL (OU with Linux), several security groups are created in the corresponding OU.

The number of security groups depends on the requested service.

Each security group has specific privileges associated, which are defined below for each service.

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

User Management

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>

User Management

This allows the user to obtain the permission for all managed 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 RHEL

In the OU /ESC/ESC_Res/ESC_Server/ESC_MOS-LNX-<BG IDx>/ESC_MOS-LNX-<BG IDx>-Access there 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 VM. 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 Swisscom operation team
`DL_ESC-MOS-LNX-Access_<hostname>_S_04`	Allows elevated privileged access - but only when the VM is in the Temp Admin state Allow the usage of all commands via sudo

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 in the OU /ESCCU01 automatically gets an UID > 1'000'000'000 and GID 9999
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 gid number attribute by yourself. If the attributes are changed, they are reset by the scheduled task. The following attributes will be defined with the scheduled 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 check checkmate to assess the membership and permission of local accounts.
Consult the Technical Description for more information about the Swisscom compliance check checkmate.

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 exist 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 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 Swisscom 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 RHEL

# User Management restrictions for Managed RHEL

# Local groups to allow local users for ssh

# Create local users if they already exist in the Active Directory resource domain

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

# Enable ssh login restriction for older Managed RHEL VMs

User Management

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 RHEL

User Management restrictions for Managed RHEL

Local groups to allow local users for ssh

Create local users if they already exist in the Active Directory resource domain

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

Enable ssh login restriction for older Managed RHEL VMs