The content to be tried from now on will be the content that was actually verified based on the content written in the following Microsoft public information.
-Reference information Join a CentOS Linux virtual machine to a managed domain in Azure AD Domain Services URL:https://docs.microsoft.com/ja-jp/azure/active-directory-domain-services/join-centos-linux-vm#configure-the-hosts-file
-Reference information Preview: Log in to a Linux virtual machine in Azure using Azure Active Directory authentication URL:https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/login-using-aad
First, I joined CentOS as a computer to the domain of Azure AD DS and tried to make SSH connection as an Azure AD user. Second, I tried using the public preview feature "Log in using Azure AD credentials" to make an SSH connection to CentOS as an Azure AD user.
One of the benefits of joining a Linux OS, including CentOS, to a domain in Azure AD DS is the credentials of users synced from Azure AD (including users synced from on-pre-AD via Azure AD Connect) to Azure AD DS. The point is that you can use to make an SSH connection to Linux OS.
This means that you don't have to create and manage users on CentOS, and you can also take advantage of Azure AD DS lockout policies and more.
Also, in the case of CentOS, if it is CentOS 6 and CentOS 7 series, although it is a public preview function, you can use the function of logging in using *** Azure AD credentials, so Azure AD DS Azure AD users can now make SSH connections without having to join a managed domain.
If you want to see only the public preview feature, click here (https://qiita.com/Shinya-Yamaguchi/items/da8d74800a811ca66879#azure-active-directory-%E8%AA%8D%E8%A8%BC% E3% 82% 92% E4% BD% BF% E7% 94% A8% E3% 81% 97% E3% 81% A6-ssh-% E6% 8E% A5% E7% B6% 9A% E3% 81% 99 Please jump to the relevant procedure from the link (% E3% 82% 8B% E6% 89% 8B% E9% A0% 86).
I tried SSH connection with the following two versions of CentOS.
OS | Authentication method |
---|---|
CentOS 8.1 | Ssh connection after joining Azure AD DS domain |
CentOS 7.5 | Log in using your Azure AD credentials(preview)SSH connection with the function of |
When you create a virtual machine on CentOS 8.1, you cannot enable it because the "Login using Azure AD credentials" function is not supported as shown in the screen shot below.
According to Microsoft's public information, the following Linux distributions and versions are supported.
-Reference information Preview: Log in to Azure Linux virtual machines using Azure Active Directory authentication Supported Azure regions and Linux distributions URL:https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/login-using-aad#supported-azure-regions-and-linux-distributions
The following Linux distributions are supported during the preview period for this feature:
Distribution | Version |
---|---|
CentOS | CentOS 6、CentOS 7 |
Debian | Debian 9 |
openSUSE | openSUSE Leap 42.3 |
RedHat Enterprise Linux | RHEL 6、RHEL 7 |
SUSE Linux Enterprise Server | SLES 12 |
Ubuntu Server | Ubuntu 14.04 LTS、Ubuntu Server 16.04、Ubuntu Server 18.04 |
After connecting to the target computer with SSH, configure the hosts file as shown below. The local host is the Azure AD DS managed domain name and the host name of the computer that joins that domain.
[root@CentOS-001 etc]# diff ./hosts ./hosts.org
1c1
< 127.0.0.1 adds001.work CentOS-001
---
> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
Then use the yum command to install the packages needed to join Azure AD DS.
[root@CentOS-001 etc]# yum install realmd sssd krb5-workstation krb5-libs oddjob oddjob-mkhomedir samba-common-tools
CentOS-8 - AppStream 25 kB/s | 3.5 kB 00:00
CentOS-8 - Base 515 kB/s | 3.1 kB 00:00
CentOS-8 - Extras 2.3 kB/s | 1.5 kB 00:00
Package realmd-0.16.3-16.el8.x86_64 is already installed.
Package sssd-2.2.0-19.el8_1.1.x86_64 is already installed.
Package krb5-libs-1.17-9.el8.x86_64 is already installed.
Dependencies resolved.
==============================================================================================================================
Package Architecture Version Repository Size
==============================================================================================================================
Installing:
oddjob x86_64 0.34.4-7.el8 AppStream 83 k
oddjob-mkhomedir x86_64 0.34.4-7.el8 AppStream 52 k
krb5-workstation x86_64 1.17-9.el8 BaseOS 940 k
samba-common-tools x86_64 4.10.4-101.el8_1 BaseOS 469 k
Installing dependencies:
libkadm5 x86_64 1.17-9.el8 BaseOS 184 k
psmisc x86_64 23.1-3.el8 BaseOS 151 k
samba-libs x86_64 4.10.4-101.el8_1 BaseOS 185 k
Transaction Summary
==============================================================================================================================
Install 7 Packages
Total download size: 2.0 M
Installed size: 6.1 M
Is this ok [y/N]: Y
Downloading Packages:
(1/7): oddjob-mkhomedir-0.34.4-7.el8.x86_64.rpm 60 kB/s | 52 kB 00:00
(2/7): krb5-workstation-1.17-9.el8.x86_64.rpm 1.0 MB/s | 940 kB 00:00
(3/7): oddjob-0.34.4-7.el8.x86_64.rpm 88 kB/s | 83 kB 00:00
(4/7): libkadm5-1.17-9.el8.x86_64.rpm 751 kB/s | 184 kB 00:00
(5/7): psmisc-23.1-3.el8.x86_64.rpm 388 kB/s | 151 kB 00:00
(6/7): samba-libs-4.10.4-101.el8_1.x86_64.rpm 792 kB/s | 185 kB 00:00
(7/7): samba-common-tools-4.10.4-101.el8_1.x86_64.rpm 1.0 MB/s | 469 kB 00:00
------------------------------------------------------------------------------------------------------------------------------
Total 1.5 MB/s | 2.0 MB 00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : psmisc-23.1-3.el8.x86_64 1/7
Installing : oddjob-0.34.4-7.el8.x86_64 2/7
Running scriptlet: oddjob-0.34.4-7.el8.x86_64 2/7
Installing : samba-libs-4.10.4-101.el8_1.x86_64 3/7
Installing : libkadm5-1.17-9.el8.x86_64 4/7
Installing : krb5-workstation-1.17-9.el8.x86_64 5/7
Installing : samba-common-tools-4.10.4-101.el8_1.x86_64 6/7
Installing : oddjob-mkhomedir-0.34.4-7.el8.x86_64 7/7
Running scriptlet: oddjob-mkhomedir-0.34.4-7.el8.x86_64 7/7
Verifying : oddjob-0.34.4-7.el8.x86_64 1/7
Verifying : oddjob-mkhomedir-0.34.4-7.el8.x86_64 2/7
Verifying : krb5-workstation-1.17-9.el8.x86_64 3/7
Verifying : libkadm5-1.17-9.el8.x86_64 4/7
Verifying : psmisc-23.1-3.el8.x86_64 5/7
Verifying : samba-common-tools-4.10.4-101.el8_1.x86_64 6/7
Verifying : samba-libs-4.10.4-101.el8_1.x86_64 7/7
Installed:
oddjob-0.34.4-7.el8.x86_64 oddjob-mkhomedir-0.34.4-7.el8.x86_64 krb5-workstation-1.17-9.el8.x86_64
samba-common-tools-4.10.4-101.el8_1.x86_64 libkadm5-1.17-9.el8.x86_64 psmisc-23.1-3.el8.x86_64
samba-libs-4.10.4-101.el8_1.x86_64
Complete!
Then use the "realm discover" command to find the Azure AD DS managed domain you want to join. If the search is successful, the following response will be returned.
[root@CentOS-001 etc]# realm discover adds001.work
adds001.work
type: kerberos
realm-name: ADDS001.WORK
domain-name: adds001.work
configured: no
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools
If you intentionally specify a domain that does not exist, you will get a message that it cannot be found.
[root@CentOS-001 etc]# realm discover adds001.work2
realm: No such realm found: adds001.work2
Then use the "kinit" command to initialize Kerberos. The user you specify here is a user who is already synced from Azure AD to Azure AD DS. Also, as mentioned in the public information, the name of the managed domain name must be specified in *** all uppercase ***.
If you do not specify uppercase letters, subsequent domain joins will fail with *** KDC reply did not match expectations while getting initial credentials *** (domain is angry with lowercase letters).
[root@CentOS-001 etc]# kinit [email protected]
Password for [email protected]:
Finally, use the "realm join" command to join the Azure AD DS managed domain. The user specified at this time is the same user specified by the kinit command earlier and is executed. Also, be sure to specify the managed domain name in *** uppercase ***.
Another addictive point is that in order to run the "realm join" command to join the domain, it must be run as a user in the "AAD DC Administrators" group in Azure AD. The following groups.
Even if I execute the "realm join" command as a user who does not belong to this group, it says "realm: Couldn't join realm: Insufficient permissions to join the domain" and gets angry if I do not have permission to join the domain. ..
If you execute it as a user who joined the "AAD DC Administrators" group as shown below, the domain will be joined successfully.
[root@CentOS-001 etc]# realm join --verbose ADDS001.WORK -U '[email protected]'
* Resolving: _ldap._tcp.adds001.work
* Performing LDAP DSE lookup on: 10.0.128.4
* Performing LDAP DSE lookup on: 10.0.128.5
* Successfully discovered: adds001.work
Password for [email protected]:
* Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/sbin/adcli
* LANG=C /usr/sbin/adcli join --verbose --domain adds001.work --domain-realm ADDS001.WORK --domain-controller 10.0.128.4 --login-type user --login-user [email protected] --stdin-password
* Using domain name: adds001.work
* Calculated computer account name from fqdn: ADDS001
* Using domain realm: adds001.work
* Sending netlogon pings to domain controller: cldap://10.0.128.4
* Received NetLogon info from: YPQT7E6FN35QB2T.adds001.work
* Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-RUnvLC/krb5.d/adcli-krb5-conf-Gni9DF
* Authenticated as user: [email protected]
* Looked up short domain name: ADDS001
* Looked up domain SID: S-1-5-21-725261351-3815095135-1752245733
* Using fully qualified name: adds001.work
* Using domain name: adds001.work
* Using computer account name: ADDS001
* Using domain realm: adds001.work
* Calculated computer account name from fqdn: ADDS001
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* Computer account for ADDS001$ does not exist
* Found well known computer container at: OU=AADDC Computers,DC=adds001,DC=work
* Calculated computer account: CN=ADDS001,OU=AADDC Computers,DC=adds001,DC=work
* Encryption type [16] not permitted.
* Encryption type [23] not permitted.
* Encryption type [3] not permitted.
* Encryption type [1] not permitted.
* Created computer account: CN=ADDS001,OU=AADDC Computers,DC=adds001,DC=work
* Sending netlogon pings to domain controller: cldap://10.0.128.4
* Received NetLogon info from: YPQT7E6FN35QB2T.adds001.work
* Set computer password
* Retrieved kvno '2' for computer account in directory: CN=ADDS001,OU=AADDC Computers,DC=adds001,DC=work
* Checking RestrictedKrbHost/adds001.work
* Added RestrictedKrbHost/adds001.work
* Checking RestrictedKrbHost/ADDS001
* Added RestrictedKrbHost/ADDS001
* Checking host/adds001.work
* Added host/adds001.work
* Checking host/ADDS001
* Added host/ADDS001
* Discovered which keytab salt to use
* Added the entries to the keytab: [email protected]: FILE:/etc/krb5.keytab
* Added the entries to the keytab: host/[email protected]: FILE:/etc/krb5.keytab
* Added the entries to the keytab: host/[email protected]: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/[email protected]: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/[email protected]: FILE:/etc/krb5.keytab
* /usr/bin/systemctl enable sssd.service
* /usr/bin/systemctl restart sssd.service
* /usr/bin/sh -c /usr/bin/authselect select sssd with-mkhomedir --force && /usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.service
Profile "sssd" was selected.
The following nsswitch maps are overwritten by the profile:
- passwd
- group
- netgroup
- automount
- services
Make sure that SSSD service is configured and enabled. See SSSD documentation for more information.
- with-mkhomedir is selected, make sure pam_oddjob_mkhomedir module
is present and oddjobd service is enabled
- systemctl enable oddjobd.service
- systemctl start oddjobd.service
Created symlink /etc/systemd/system/multi-user.target.wants/oddjobd.service → /usr/lib/systemd/system/oddjobd.service.
* Successfully enrolled machine in realm
At this point, if you check the Azure AD DS "AADDC Computers" OU, you can see that such computers are joined.
SSH public key authentication is selected by default when creating an Azure VM. To enable password authentication, enable PasswordAuthentication in sshd_config. If password authentication was selected when creating the VM, this setting is already "yes".
[root@CentOS-001 ssh]# pwd
/etc/ssh
[root@CentOS-001 ssh]# cat ./sshd_config | grep PasswordAuthentication
#PasswordAuthentication yes
PasswordAuthentication yes
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication, then enable this but set PasswordAuthentication
Configure settings to grant sudo privileges to members in the AAD DC Administrators group in Azure AD DS.
sudo visudo
[root@CentOS-001 etc]# diff ./sudoers ./sudoers.org
121,123d120
<
< # Add 'AAD DC Administrators' group members as admins.
< %AAD\ DC\ [email protected] ALL=(ALL) NOPASSWD:ALL
Now that you're ready, let's see if the Azure AD DS user ([email protected]) synced from Azure AD from the SSH client can ssh to the target CentOS.
I was able to connect without any problems.
Try to have root privileges with sudo.
[[email protected]@CentOS-001 ~]$ sudo su -
Last login: Sat May 2 16:55:36 UTC 2020 on pts/0
Last failed login: Sat May 2 17:24:28 UTC 2020 from 209.141.55.11 on ssh:notty
There were 2 failed login attempts since the last successful login.
[root@CentOS-001 ~]#
[root@CentOS-001 ~]#
I was able to promote to root without any problems.
This completes the procedure for joining an Azure AD DS managed domain and making an SSH connection with an Azure AD user. Next, try another pattern, the public preview feature, "Procedure for SSH connection using Azure Active Directory authentication."
This procedure does not require any difficult work as it only installs the Azure VM extension when or after creating the Azure VM. Instructions for installing the extension can also be found in the public information below.
-Reference information Install the Azure AD login VM extension URL:https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/login-using-aad#install-the-azure-ad-login-vm-extension
I tried various things, but RHEL and Ubuntu OS can enable the function from "Login using Azure AD credentials" from the virtual machine creation screen of the Azure portal as shown in the screen shot below. However, it was not possible to enable it at the time of VM creation in any of CentOS 6 series and 7 series, which are said to be supported in the case of CentOS.
Therefore, install and try the VM extension described in the above public information.
First, launch Cloud Shell from the Azure portal and run the following cmdlet to install the VM extension as described in the public information. Replace * myResourceGroup * and * myVM * with the name of the environment to be executed as appropriate.
az vm extension set \
--publisher Microsoft.Azure.ActiveDirectory.LinuxSSH \
--name AADLoginForLinux \
--resource-group myResourceGroup \
--vm-name myVM
If the installation is successful, * provisioningState * will be output as * Succeeded * as shown in the screen shot below.
Then assign the target virtual machine the role of RBAC (Role Based Access Control) required to make an SSH connection. As stated in the public information, users who are assigned the "owner" or "co-author" role of the virtual machine also cannot make SSH connections. Therefore, you must explicitly assign the role of *** virtual machine administrator login *** or *** virtual machine user login ***.
There is no problem if you assign it from the Azure portal as shown in the screen shot above, but since Cloud Shell is open, assign "Virtual machine administrator login" with the az role assignment create cmdlet as shown below. to watch.
Also, in the public information, username specifies the running user of Cloud Shell, but in the item "Procedure to join Azure AD DS managed domain and SSH connection with Azure AD user", it belongs to "AAD DC Administrators" group. You have given the user the right to SSH.
Therefore, in order to set the target of assignee to "AAD DC Administrators", extract the objectId from the group name "AAD DC Administrators" and modify it to the command specified by the "--assignee-object-id" option as shown below. doing.
groupid=$(az ad group list --filter "displayname eq 'AAD DC Administrators'" --query "[].objectId" --output tsv)
vm=$(az vm show --resource-group myResourceGroup --name myVM --query id -o tsv)
az role assignment create \
--role "Virtual Machine Administrator Login" \
--assignee-object-id $groupid \
--scope $vm
The screen shot below is an example of successful execution.
Now you're ready to make an SSH connection with your Azure AD user. Let's connect from the SSH client right away.
Although it is specified by the ssh -l command in the public information, I want you to know the image when you make an SSH connection to the Azure VM of Linux OS for the first time using the SSH client, so the following contents are described.
When joining a managed domain of Azure AD DS, authentication is performed using "user name" and "password", but when using the VM extension function of this "Azure Active Directory authentication", "interactive" You need to make an SSH connection with "Authentication".
For example, when using Tera Term, select "Use keyboard interactive authentication" as shown in the screen shot below to authenticate.
However, there is a caveat here. This is a true story like a lie, but when performing interactive authentication with Tera Term, the essential authentication code does not fit on the screen and cannot be seen as shown in the screen shot below.
Therefore, when using TeraTerm, it seems necessary to make an SSH connection from the prompt with the SSH connection already made from the bastion server.
I can't show the actual screen with Tera Term, so I will try it with PuTTY. If you specify an Azure AD user who is a member of the "AAD DC Administrators" group in PuTTY login as and press Enter, you will be prompted to enter the code as shown in the screen shot below, the URL to enter the code. Will be "https://microsoft.com/devicelogin". Let's access it.
Enter (paste) the code displayed on the PuTTY screen as shown in the screen shot below, and click "Next".
If the user you want to authenticate is not in the list, click Use another account.
Enter the target Azure AD user and click Next.
Enter your password and click Sign In.
Sign-in is complete. It's okay to close this window as described.
When you press Enter on the PuTTY screen, you can confirm that you can connect to the target CentOS machine as an Azure AD user as shown in the screen shot below.
Code authentication is required in the same way when sudo is performed by a general user, but if re-authentication is not required, you can skip re-authentication by editing the "aad_admins" file below.
[root@centos-002-7 sudoers.d]# diff ./aad_admins ./aad_admins.org
1c1
< %aad_admins ALL=(ALL) NOPASSWD:ALL
---
> %aad_admins ALL=(ALL) ALL
\ No newline at end of file
Something like this.
[[email protected]@centos-002-7 ~]$ sudo su -
Last login: Sun May 3 17:28:21 UTC 2020 on pts/0
[root@centos-002-7 ~]#
As an added bonus, since you are authenticating as an Azure AD user, you can also use conditional access to require multi-factor authentication during SSH connection authentication. The image looks like the following.
First, code authenticate the device. Enter the code and click Next.
If your account is not in the list, click Use another account.
Enter your user name and click Next.
Enter your password and click Sign In. This is the authentication using normal credentials.
You will be prompted to open the Microsoft Authenticator app and respond as shown in the screen shot below. This is because the target user has set up the Microsoft Authenticator app in advance and is set to use this app for multi-factor authentication.
The following notification will be sent to the smartphone running the Microsoft Authenticator app, so tap it.
Do you want to approve the sign-in? Is displayed, tap "Approve".
Now that multi-factor authentication is complete, close the screen below and press Enter on the PuTTY screen to complete the SSH connection.
This time, in order to SSH connect CentOS on Azure VM using Azure AD user, we will use the method of joining "Managed Domain of Azure AD DS" and the public preview function "Azure Active Directory Authentication". And SSH connection procedure I tried to verify the operation of each of the two types of patterns.
If you've seen both steps, you'll notice that the latter, the public preview feature, is overwhelmingly easier to set up. The reason is that you don't need to prepare an Azure AD DS environment in the first place, and you can complete the work in Cloud Shell (Azure CLI).
On the other hand, there is still a concern that the Azure VM extension "Azure Active Directory Authentication" is not a "public preview" feature, that is, GA (regular version).
At this point, it may be more appropriate to choose to join Azure AD DS in an environment where there is a rule that you should only use the GA version in your production environment.
Although wishful thinking, this public preview feature is very useful not only for Linux OS but also for Windows OS. Since it authenticates using an Azure AD user, you can also request multi-factor authentication as shown, improving authentication security. From this point of view, I don't know when it will be, but I personally think that it is a function that will be GA.
I hope you find this article helpful.