Der Inhalt, der von nun an ausprobiert werden soll, ist der Inhalt, der tatsächlich anhand des Inhalts überprüft wurde, der in den folgenden öffentlichen Informationen von Microsoft geschrieben wurde.
-Referenzinformationen Verbinden Sie eine virtuelle CentOS Linux-Maschine mit einer von Azure AD Domain Services verwalteten Domäne URL:https://docs.microsoft.com/ja-jp/azure/active-directory-domain-services/join-centos-linux-vm#configure-the-hosts-file
-Referenzinformationen Vorschau: Melden Sie sich mit der Azure Active Directory-Authentifizierung bei einer virtuellen Azure Linux-Maschine an URL:https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/login-using-aad
Die erste bestand darin, CentOS als Computer mit der Azure AD DS-Domäne zu verbinden und zu prüfen, ob Azure AD-Benutzer SSH-Verbindungen herstellen können. Zweitens habe ich versucht, mithilfe der öffentlichen Vorschaufunktion "Mit Azure AD-Anmeldeinformationen anmelden" eine SSH-Verbindung zu CentOS als Azure AD-Benutzer herzustellen.
Einer der Vorteile des Beitritts eines Linux-Betriebssystems, einschließlich CentOS, zur Azure AD DS-Domäne sind die Anmeldeinformationen von Benutzern, die von Azure AD (einschließlich Benutzern, die vor dem AD über Azure AD Connect synchronisiert wurden) mit Azure AD DS synchronisiert wurden. Der Punkt ist, dass Sie verwenden können, um eine SSH-Verbindung zum Linux-Betriebssystem herzustellen.
Dies bedeutet, dass Sie unter CentOS keine Benutzer erstellen und verwalten müssen. Außerdem können Sie die Sperrrichtlinien von Azure AD DS und mehr nutzen.
Im Fall von CentOS können Sie in CentOS 6- und CentOS 7-Serien, obwohl es sich um eine öffentliche Vorschaufunktion handelt, die Funktion zum Anmelden mit *** Azure AD-Anmeldeinformationen verwenden, sodass Sie Azure AD DS verwenden können. Azure AD-Benutzer können jetzt SSH-Verbindungen herstellen, ohne einer verwalteten Domäne beitreten zu müssen.
Wenn Sie nur die öffentliche Vorschau sehen möchten, klicken Sie hier (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 Bitte springen Sie über den Link von% E3% 82% 8B% E6% 89% 8B% E9% A0% 86) zum entsprechenden Verfahren.
Ich habe versucht, eine SSH-Verbindung mit den folgenden zwei Versionen von CentOS herzustellen.
OS | Authentifizierungsmethode |
---|---|
CentOS 8.1 | SSH-Verbindung nach dem Beitritt zur Azure AD DS-Domäne |
CentOS 7.5 | Melden Sie sich mit Ihren Azure AD-Anmeldeinformationen an(Vorschau)SSH-Verbindung mit der Funktion von |
Wenn Sie eine virtuelle Maschine mit CentOS 8.1 erstellen, können Sie sie nicht aktivieren, da die Funktion "Anmelden mit Azure AD-Anmeldeinformationen" nicht unterstützt wird (siehe Abbildung unten).
Nach den öffentlichen Informationen von Microsoft werden die folgenden Linux-Distributionen und -Versionen unterstützt.
-Referenzinformationen Vorschau: Melden Sie sich mithilfe der Azure Active Directory-Authentifizierung bei virtuellen Azure Linux-Maschinen an. Unterstützte Azure-Regionen und Linux-Distributionen URL:https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/login-using-aad#supported-azure-regions-and-linux-distributions
Die folgenden Linux-Distributionen werden während des Vorschauzeitraums für diese Funktion unterstützt:
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 |
Nachdem Sie mit SSH eine Verbindung zum Zielcomputer hergestellt haben, konfigurieren Sie die Hosts-Datei wie unten gezeigt. Der lokale Host ist der verwaltete Azure AD DS-Domänenname und der Hostname des Computers, der dieser Domäne beitritt.
[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
Verwenden Sie dann den Befehl yum, um die Pakete zu installieren, die für den Beitritt zu Azure AD DS erforderlich sind.
[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!
Verwenden Sie dann den Befehl "Realm Discovery", um die von Azure AD DS verwaltete Domäne zu finden, der Sie beitreten möchten. Wenn die Suche erfolgreich ist, wird die folgende Antwort zurückgegeben.
[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
Wenn Sie absichtlich eine Domäne angeben, die nicht vorhanden ist, erhalten Sie die Meldung, dass sie nicht gefunden werden kann.
[root@CentOS-001 etc]# realm discover adds001.work2
realm: No such realm found: adds001.work2
Verwenden Sie dann den Befehl "kinit", um Kerberos zu initialisieren. Der hier angegebene Benutzer gibt einen Benutzer an, der bereits von Azure AD mit Azure AD DS synchronisiert ist. Wie in den öffentlichen Informationen erwähnt, muss der Name des verwalteten Domänennamens in *** Großbuchstaben *** angegeben werden.
Wenn Sie keine Großbuchstaben angeben, schlagen nachfolgende Domain-Joins mit *** fehl. Die KDC-Antwort entsprach nicht den Erwartungen, während die ersten Anmeldeinformationen abgerufen wurden *** (Domain ist wütend auf Kleinbuchstaben).
[root@CentOS-001 etc]# kinit [email protected]
Password for [email protected]:
Verwenden Sie abschließend den Befehl "Realm Join", um der von Azure AD DS verwalteten Domäne beizutreten. Der zu diesem Zeitpunkt angegebene Benutzer ist derselbe Benutzer, der zuvor im Befehl kinit angegeben wurde, und wird ausgeführt. Stellen Sie außerdem sicher, dass Sie den Namen der verwalteten Domain in *** Großbuchstaben *** angeben.
Eine weitere Sucht besteht darin, dass der Befehl "Realm Join" zum Beitritt zur Domäne von einem Benutzer ausgeführt werden muss, der zur Gruppe "AAD DC-Administratoren" in Azure AD gehört. Die folgenden Gruppen.
Selbst wenn ich den Befehl "Realm Join" als Benutzer ausführe, der nicht zu dieser Gruppe gehört, heißt es "Realm: Konnte nicht dem Realm beitreten: Unzureichende Berechtigungen zum Beitritt zur Domäne" und wird wütend, wenn ich keine Berechtigung zum Beitritt zur Domäne habe. ..
Wenn Sie es als Benutzer ausführen, der wie unten gezeigt der Gruppe "AAD DC-Administratoren" beigetreten ist, ist der Domänenbeitritt erfolgreich.
[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
Wenn Sie zu diesem Zeitpunkt die Organisationseinheit "AADDC-Computer" von Azure AD DS überprüfen, können Sie feststellen, dass solche Computer verbunden sind.
Die Authentifizierung mit öffentlichem SSH-Schlüssel ist beim Erstellen einer Azure-VM standardmäßig ausgewählt. Um die Kennwortauthentifizierung zu aktivieren, aktivieren Sie die Kennwortauthentifizierung in sshd_config. Wenn beim Erstellen der VM die Kennwortauthentifizierung ausgewählt wurde, lautet diese Einstellung bereits "Ja".
[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
Konfigurieren Sie Einstellungen, um Mitgliedern in der Gruppe AAD DC-Administratoren von Azure AD DS Sudo-Berechtigungen zu erteilen.
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
Nachdem Sie fertig sind, sehen wir uns an, ob der von Azure AD vom SSH-Client synchronisierte Azure AD DS-Benutzer ([email protected]) SSH in das Ziel-CentOS ausführen kann.
Ich konnte mich ohne Probleme verbinden.
Versuchen Sie, mit sudo Root-Rechte zu haben.
[[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 ~]#
Ich konnte ohne Probleme zum Rooten aufsteigen.
Damit ist der Vorgang zum Beitritt zu einer von Azure AD DS verwalteten Domäne und zum Herstellen einer SSH-Verbindung mit einem Azure AD-Benutzer abgeschlossen. Versuchen Sie als Nächstes ein anderes Muster, die öffentliche Vorschaufunktion "Verfahren für die SSH-Verbindung mithilfe der Azure Active Directory-Authentifizierung".
Dieses Verfahren erfordert keine schwierige Arbeit, da Sie die Azure VM-Erweiterung nur beim oder nach dem Erstellen der Azure VM installieren müssen. Anweisungen zur Installation der Erweiterung finden Sie auch in den folgenden öffentlichen Informationen.
-Referenzinformationen Installieren Sie die Azure AD-Anmelde-VM-Erweiterung URL:https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/login-using-aad#install-the-azure-ad-login-vm-extension
Ich habe verschiedene Dinge ausprobiert, aber RHEL und Ubuntu OS können die Funktion "Anmelden mit Azure AD-Anmeldeinformationen" über den Erstellungsbildschirm der virtuellen Maschine des Azure-Portals aktivieren (siehe Abbildung unten). Es war jedoch zum Zeitpunkt der VM-Erstellung in keiner der CentOS 6- und 7-Serien möglich, die im Fall von CentOS unterstützt werden sollen.
Installieren und testen Sie daher die in den obigen öffentlichen Informationen beschriebene VM-Erweiterung.
Starten Sie zunächst die Cloud Shell über das Azure-Portal und führen Sie das folgende Cmdlet aus, um die VM-Erweiterung wie in den öffentlichen Informationen beschrieben zu installieren. Ersetzen Sie * myResourceGroup * und * myVM * durch den Namen der Umgebung, die entsprechend ausgeführt werden soll.
az vm extension set \
--publisher Microsoft.Azure.ActiveDirectory.LinuxSSH \
--name AADLoginForLinux \
--resource-group myResourceGroup \
--vm-name myVM
Wenn die Installation erfolgreich ist, wird * provisioningState * als * erfolgreich * ausgegeben (siehe Abbildung unten).
Weisen Sie dann der virtuellen Zielmaschine die für die SSH-Verbindung erforderliche RBAC-Rolle (Role Based Access Control) zu. Wie in den öffentlichen Informationen angegeben, können Benutzer, denen die Rolle "Eigentümer" oder "Mitautor" der virtuellen Maschine zugewiesen wurde, keine SSH-Verbindungen herstellen. Daher müssen Sie explizit die Rolle der Administratoranmeldung für virtuelle Maschinen *** oder der Benutzeranmeldung für virtuelle Maschinen *** zuweisen.
Es ist kein Problem, wenn Sie es über das Azure-Portal zuweisen, wie im obigen Screenshot gezeigt. Da Cloud Shell jedoch geöffnet ist, weisen Sie "Administratoranmeldung für virtuelle Maschinen" mit dem Cmdlet "Az-Rollenzuweisung erstellen" wie unten gezeigt zu. schauen.
In den öffentlichen Informationen gibt der Benutzername den Ausführungsbenutzer der Cloud Shell an. Im Element "Verfahren zum Beitritt zur verwalteten Azure AD DS-Domäne und zur SSH-Verbindung mit dem Azure AD-Benutzer" gehört er jedoch zur Gruppe "AAD DC-Administratoren". Ich habe dem Benutzer das Recht auf SSH eingeräumt.
Um "AAD DC-Administratoren" auf "AAD DC-Administratoren" auszurichten, extrahieren Sie daher die Objekt-ID aus dem Gruppennamen "AAD DC-Administratoren" und ändern Sie sie in den Befehl, der durch die Option "--assignee-object-id" angegeben wird (siehe unten). tun.
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
Der folgende Screenshot ist ein Beispiel für eine erfolgreiche Ausführung.
Jetzt können Sie SSH in Ihren Azure AD-Benutzer einbinden. Lassen Sie uns sofort eine Verbindung vom SSH-Client herstellen.
Die öffentlichen Informationen werden durch den Befehl ssh -l angegeben. Da Sie jedoch das Image kennen sollen, wenn SSH zum ersten Mal über den SSH-Client eine Verbindung zur Azure VM des Linux-Betriebssystems herstellt, werden die folgenden Inhalte beschrieben.
Beim Beitritt zu einer verwalteten Domäne von Azure AD DS wird die Authentifizierung mit "Benutzername" und "Kennwort" durchgeführt. Wenn Sie jedoch die VM-Erweiterungsfunktion dieser "Azure Active Directory-Authentifizierung" verwenden, wird "interaktiv" verwendet. Sie müssen eine SSH-Verbindung mit "Authentifizierung" herstellen.
Wenn Sie beispielsweise Tera Term verwenden, wählen Sie "Interaktive Tastaturauthentifizierung verwenden" (siehe Abbildung unten), um sich zu authentifizieren.
Hier gibt es jedoch eine Einschränkung. Dies ist eine wahre Geschichte wie eine Lüge, aber wenn Sie eine interaktive Authentifizierung mit Tera Term durchführen, können Sie den wesentlichen Authentifizierungscode nicht sehen, da er nicht auf den Bildschirm passt, wie in der Abbildung unten gezeigt.
Daher scheint es bei Verwendung von TeraTerm erforderlich zu sein, an der Eingabeaufforderung eine SSH-Verbindung herzustellen, wobei die SSH-Verbindung bereits vom Plattformserver hergestellt wurde.
Ich kann den tatsächlichen Bildschirm mit Tera Term nicht anzeigen, also werde ich es mit PuTTY versuchen. Wenn Sie in der PuTTY-Anmeldung als einen Azure AD-Benutzer angeben, der Mitglied der Gruppe "AAD DC-Administratoren" ist, und die Eingabetaste drücken, werden Sie aufgefordert, den Code wie im folgenden Screenshot gezeigt einzugeben, die URL, um den Code einzugeben. Wird "https://microsoft.com/devicelogin" sein. Lassen Sie uns darauf zugreifen.
Geben Sie den auf dem PuTTY-Bildschirm angezeigten Code ein (fügen Sie ihn ein), wie in der Abbildung unten gezeigt, und klicken Sie auf "Weiter".
Wenn der Benutzer, den Sie authentifizieren möchten, nicht in der Liste enthalten ist, klicken Sie auf Anderes Konto verwenden.
Geben Sie den gewünschten Azure AD-Benutzer ein und klicken Sie auf Weiter.
Geben Sie Ihr Passwort ein und klicken Sie auf Anmelden.
Die Anmeldung ist abgeschlossen. Es ist in Ordnung, dieses Fenster wie beschrieben zu schließen.
Wenn Sie auf dem PuTTY-Bildschirm die Eingabetaste drücken, können Sie bestätigen, dass Sie als Azure AD-Benutzer eine Verbindung zum CentOS-Zielcomputer herstellen können (siehe Abbildung unten).
Die Codeauthentifizierung ist auf die gleiche Weise erforderlich, wenn sudo von einem allgemeinen Benutzer ausgeführt wird. Wenn jedoch keine erneute Authentifizierung erforderlich ist, können Sie die erneute Authentifizierung überspringen, indem Sie die folgende Datei "aad_admins" bearbeiten.
[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
Etwas wie das.
[[email protected]@centos-002-7 ~]$ sudo su -
Last login: Sun May 3 17:28:21 UTC 2020 on pts/0
[root@centos-002-7 ~]#
Als Bonus von hier aus können Sie, da Sie sich als Azure AD-Benutzer authentifizieren, auch den bedingten Zugriff verwenden, um während der SSH-Verbindungsauthentifizierung eine Multi-Faktor-Authentifizierung zu erfordern. Das Bild sieht wie folgt aus.
Zunächst wird die Codeauthentifizierung des Geräts durchgeführt. Geben Sie den Code ein und klicken Sie auf Weiter.
Wenn das Konto nicht in der Liste enthalten ist, klicken Sie auf "Anderes Konto verwenden".
Geben Sie Ihren Benutzernamen ein und klicken Sie auf Weiter.
Geben Sie Ihr Passwort ein und klicken Sie auf Anmelden. Dies ist die Authentifizierung mit normalen Anmeldeinformationen.
Sie werden aufgefordert, die Microsoft Authenticator-App zu öffnen und wie im folgenden Screenshot gezeigt zu antworten. Dies liegt daran, dass der Zielbenutzer die Microsoft Authenticator-App im Voraus eingerichtet hat und diese App für die Multi-Faktor-Authentifizierung verwenden soll.
Die folgende Benachrichtigung wird an das Smartphone gesendet, auf dem die Microsoft Authenticator-App ausgeführt wird. Tippen Sie also darauf.
Möchten Sie die Anmeldung genehmigen? Wird angezeigt, tippen Sie auf "Genehmigen".
Schließen Sie nach Abschluss der Multi-Faktor-Authentifizierung den folgenden Bildschirm und drücken Sie die Eingabetaste auf dem PuTTY-Bildschirm, um die SSH-Verbindung herzustellen.
Dieses Mal verwenden wir für die SSH-Verbindung von CentOS auf Azure VM mithilfe eines Azure AD-Benutzers die Methode zum Beitreten und Realisieren der "verwalteten Domäne von Azure AD DS" und der "Azure Active Directory-Authentifizierung", bei der es sich um eine öffentliche Vorschaufunktion handelt. Vorgehensweise für die SSH-Verbindung Ich habe versucht, die Funktionsweise der beiden Mustertypen zu überprüfen.
Wie Sie vielleicht bemerkt haben, wenn Sie beide Schritte gelesen haben, ist die Einrichtung mit der letztgenannten öffentlichen Vorschaufunktion überwiegend einfacher. Der Grund dafür ist, dass Sie zunächst keine Azure AD DS-Umgebung vorbereiten müssen und diese in der Cloud Shell (Azure CLI) abgeschlossen werden kann.
Andererseits besteht die Sorge, dass "Azure Active Directory-Authentifizierung", eine Erweiterung von Azure VM, keine "öffentliche Vorschau" -Funktion ist, dh GA (Originalversion).
An dieser Stelle ist es möglicherweise besser, Azure AD DS in einer Umgebung beizutreten, in der in Produktionsumgebungen in der Regel nur die GA-Version verwendet werden sollte.
Obwohl dies eine hoffnungsvolle Beobachtung ist, ist diese öffentliche Vorschaufunktion sehr praktisch, da sie nicht nur für Linux-Betriebssysteme, sondern auch für Windows-Betriebssysteme verwendet werden kann. Da die Authentifizierung mithilfe von Azure AD-Benutzern erfolgt, kann wie gezeigt eine Multi-Faktor-Authentifizierung angefordert werden, wodurch die Authentifizierungssicherheit verbessert wird. Unter diesem Gesichtspunkt weiß ich nicht, wann es sein wird, aber ich persönlich denke, dass es eine Funktion ist, die GA sein wird.
Ich hoffe, Sie finden diesen Artikel hilfreich.