Le contenu à essayer à partir de maintenant sera le contenu qui a été réellement vérifié sur la base du contenu écrit dans les informations publiques Microsoft suivantes.
-Informations de référence Joindre une machine virtuelle CentOS Linux à un domaine géré Azure AD Domain Services URL:https://docs.microsoft.com/ja-jp/azure/active-directory-domain-services/join-centos-linux-vm#configure-the-hosts-file
-Informations de référence Aperçu: connectez-vous à une machine virtuelle Azure Linux à l'aide de l'authentification Azure Active Directory URL:https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/login-using-aad
La première était de joindre CentOS en tant qu'ordinateur au domaine Azure AD DS et de voir si les utilisateurs d'Azure AD pouvaient établir des connexions SSH. Deuxièmement, j'ai essayé d'utiliser la fonctionnalité de prévisualisation publique «Connectez-vous à l'aide des informations d'identification Azure AD» pour établir une connexion SSH à CentOS en tant qu'utilisateur Azure AD.
L'un des avantages de rejoindre un système d'exploitation Linux, y compris CentOS, au domaine Azure AD DS réside dans les informations d'identification des utilisateurs synchronisés depuis Azure AD (y compris les utilisateurs synchronisés à partir de la version pré-AD via Azure AD Connect) vers Azure AD DS. Le fait est que vous pouvez utiliser pour établir une connexion SSH au système d'exploitation Linux.
Cela signifie que vous n'avez pas besoin de créer et de gérer des utilisateurs sur CentOS, et que vous pouvez également profiter des stratégies de verrouillage Azure AD DS et plus encore.
De plus, dans le cas de CentOS, dans les séries CentOS 6 et CentOS 7, bien qu'il s'agisse d'une fonction de prévisualisation publique, vous pouvez utiliser la fonction de connexion à l'aide des informations d'identification Azure AD ***, de sorte que vous pouvez utiliser Azure AD DS. Les utilisateurs d'Azure AD peuvent désormais utiliser SSH sans avoir à rejoindre un domaine géré.
Si vous souhaitez voir uniquement la fonctionnalité de prévisualisation publique, cliquez ici (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 Veuillez passer à la procédure correspondante à partir du lien de% E3% 82% 8B% E6% 89% 8B% E9% A0% 86).
J'ai essayé la connexion SSH avec les deux versions suivantes de CentOS.
OS | Méthode d'authentification |
---|---|
CentOS 8.1 | Connexion SSH après avoir rejoint le domaine Azure AD DS |
CentOS 7.5 | Connectez-vous à l'aide de vos informations d'identification Azure AD(Aperçu)Connexion SSH avec la fonction de |
Si vous créez une machine virtuelle sur CentOS 8.1, vous ne pouvez pas l'activer car la fonction «Connexion à l'aide des informations d'identification Azure AD» n'est pas prise en charge, comme illustré dans la capture d'écran ci-dessous.
Selon les informations publiques de Microsoft, les distributions et versions Linux suivantes sont prises en charge.
-Informations de référence Aperçu: Régions Azure et distributions Linux prises en charge pour se connecter aux machines virtuelles Azure Linux à l'aide de l'authentification Azure Active Directory URL:https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/login-using-aad#supported-azure-regions-and-linux-distributions
Les distributions Linux suivantes seront prises en charge pendant la période de prévisualisation de cette fonctionnalité:
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 |
Après vous être connecté à l'ordinateur cible avec SSH, configurez le fichier d'hôtes comme indiqué ci-dessous. L'hôte local est le nom de domaine géré Azure AD DS et le nom d'hôte de l'ordinateur qui rejoint ce domaine.
[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
Utilisez ensuite la commande yum pour installer les packages nécessaires pour rejoindre 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!
Utilisez ensuite la commande «realm discover» pour rechercher le domaine géré Azure AD DS que vous souhaitez rejoindre. Si la recherche réussit, la réponse suivante sera renvoyée.
[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
Si vous spécifiez intentionnellement un domaine qui n'existe pas, vous recevrez un message indiquant qu'il est introuvable.
[root@CentOS-001 etc]# realm discover adds001.work2
realm: No such realm found: adds001.work2
Utilisez ensuite la commande "kinit" pour initialiser Kerberos. L'utilisateur spécifié ici spécifie un utilisateur qui est déjà synchronisé d'Azure AD vers Azure AD DS. De plus, comme mentionné dans les informations publiques, le nom du nom de domaine géré doit être spécifié en *** toutes majuscules ***.
Si vous ne spécifiez pas de lettres majuscules, les jointures de domaine suivantes échoueront avec *** La réponse KDC ne correspond pas aux attentes lors de l'obtention des informations d'identification initiales *** (le domaine est en colère contre les lettres minuscules).
[root@CentOS-001 etc]# kinit [email protected]
Password for [email protected]:
Enfin, utilisez la commande "realm join" pour rejoindre le domaine géré Azure AD DS. L'utilisateur spécifié à ce moment est le même utilisateur spécifié par la commande kinit précédemment et est exécuté. Veillez également à indiquer le nom de domaine géré en *** majuscule ***.
Un autre point addictif est que pour exécuter la commande "realm join" pour rejoindre le domaine, il doit être exécuté par un utilisateur qui appartient au groupe "AAD DC Administrators" dans Azure AD. Les groupes suivants.
Même si j'exécute la commande "realm join" en tant qu'utilisateur n'appartenant pas à ce groupe, elle dit "royaume: impossible de rejoindre le royaume: autorisations insuffisantes pour rejoindre le domaine" et se fâche si je n'ai pas l'autorisation de rejoindre le domaine. ..
Si vous l'exécutez en tant qu'utilisateur qui a rejoint le groupe «Administrateurs AAD DC» comme indiqué ci-dessous, la jonction de domaine réussira.
[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
À ce stade, si vous vérifiez l'unité d'organisation «Ordinateurs AADDC» Azure AD DS, vous pouvez voir que ces ordinateurs sont joints.
L'authentification par clé publique SSH est sélectionnée par défaut lors de la création d'une machine virtuelle Azure. Pour activer l'authentification par mot de passe, activez PasswordAuthentication dans sshd_config. Si l'authentification par mot de passe a été sélectionnée lors de la création de la VM, ce paramètre est déjà "oui".
[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
Configurez les paramètres pour accorder des privilèges sudo aux membres du groupe Administrateurs AAD DC d'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
Maintenant que vous êtes prêt, voyons si l'utilisateur Azure AD DS ([email protected]) synchronisé à partir d'Azure AD à partir du client SSH peut SSH dans le CentOS cible.
J'ai pu me connecter sans aucun problème.
Essayez d'avoir les privilèges root avec 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 ~]#
J'ai pu promouvoir à root sans aucun problème.
Cela termine la procédure pour rejoindre un domaine géré Azure AD DS et établir une connexion SSH avec un utilisateur Azure AD. Ensuite, essayez un autre modèle, la fonctionnalité de préversion publique, «Procédures pour la connexion SSH à l'aide de l'authentification Azure Active Directory».
Cette procédure ne nécessite aucun travail difficile, car vous devez uniquement installer l'extension de machine virtuelle Azure lorsque ou après la création de la machine virtuelle Azure. Les instructions pour l'installation de l'extension peuvent également être trouvées dans les informations publiques ci-dessous.
-Informations de référence Installer l'extension de machine virtuelle de connexion Azure AD URL:https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/login-using-aad#install-the-azure-ad-login-vm-extension
J'ai essayé diverses choses, mais RHEL et Ubuntu OS peuvent activer la fonction à partir de «Connexion à l'aide des informations d'identification Azure AD» à partir de l'écran de création de machine virtuelle du portail Azure comme indiqué dans la capture d'écran ci-dessous. Cependant, il n'a pas été possible de l'activer au moment de la création de la VM dans aucune des séries CentOS 6 et 7, qui seraient prises en charge dans le cas de CentOS.
Par conséquent, installez et essayez l'extension de machine virtuelle décrite dans les informations publiques ci-dessus.
Tout d'abord, lancez Cloud Shell à partir du portail Azure et exécutez l'applet de commande suivante pour installer l'extension de machine virtuelle comme décrit dans les informations publiques. Remplacez * myResourceGroup * et * myVM * par le nom de l'environnement à exécuter selon le cas.
az vm extension set \
--publisher Microsoft.Azure.ActiveDirectory.LinuxSSH \
--name AADLoginForLinux \
--resource-group myResourceGroup \
--vm-name myVM
Si l'installation réussit, * provisioningState * sera affiché comme * Réussi * comme indiqué dans la capture d'écran ci-dessous.
Attribuez ensuite le rôle RBAC (Role Based Access Control) requis pour établir une connexion SSH avec la machine virtuelle cible. Comme indiqué dans les informations publiques, les utilisateurs qui se voient attribuer le rôle de «propriétaire» ou de «co-auteur» de la machine virtuelle ne peuvent pas non plus établir de connexions SSH. Par conséquent, vous devez explicitement attribuer le rôle de *** connexion d'administrateur de machine virtuelle *** ou de *** connexion d'utilisateur de machine virtuelle ***.
Il n'y a aucun problème si vous l'attribuez à partir du portail Azure comme indiqué dans la capture d'écran ci-dessus, mais comme Cloud Shell est ouvert, attribuez «Connexion administrateur de machine virtuelle» avec l'applet de commande de création de rôle az comme indiqué ci-dessous. regarder.
De plus, dans les informations publiques, le nom d'utilisateur spécifie l'utilisateur d'exécution de Cloud Shell, mais dans l'élément «Procédure pour rejoindre le domaine géré Azure AD DS et la connexion SSH avec l'utilisateur Azure AD», il appartient au groupe «Administrateurs AAD DC». J'ai donné à l'utilisateur le droit à SSH.
Par conséquent, afin de cibler «Administrateurs AAD DC» pour l'assigné, extrayez le objectId du nom de groupe «AAD DC Administrators» et modifiez-le à la commande spécifiée par l'option «--assignee-object-id» comme indiqué ci-dessous. Faire.
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
La capture d'écran ci-dessous est un exemple d'exécution réussie.
Vous êtes maintenant prêt à utiliser SSH dans votre utilisateur Azure AD. Connectons-nous tout de suite depuis le client SSH.
Les informations publiques sont spécifiées par la commande ssh -l, mais je souhaite que vous connaissiez l'image lors de la connexion SSH à la machine virtuelle Azure du système d'exploitation Linux pour la première fois à l'aide du client SSH.Le contenu suivant est donc décrit.
Lorsque vous rejoignez un domaine géré d'Azure AD DS, l'authentification est effectuée à l'aide de «nom d'utilisateur» et de «mot de passe», mais lors de l'utilisation de la fonction d'extension de machine virtuelle de cette «authentification Azure Active Directory», «interactive» Vous devez établir une connexion SSH avec "Authentification".
Par exemple, lorsque vous utilisez Tera Term, sélectionnez "Utiliser l'authentification interactive au clavier" comme indiqué dans la capture d'écran ci-dessous pour vous authentifier.
Cependant, il y a une mise en garde ici. C'est une histoire vraie comme un mensonge, mais lorsque vous effectuez une authentification interactive avec Tera Term, vous ne pouvez pas voir le code d'authentification essentiel car il ne rentre pas sur l'écran comme indiqué dans la capture d'écran ci-dessous.
Par conséquent, lors de l'utilisation de TeraTerm, il semble nécessaire d'établir une connexion SSH à partir de l'invite avec la connexion SSH déjà établie à partir du serveur de la plate-forme.
Je ne peux pas afficher l'écran réel avec Tera Term, je vais donc l'essayer avec PuTTY. Si vous spécifiez un utilisateur Azure AD membre du groupe «Administrateurs AAD DC» dans la connexion de PuTTY en tant que et appuyez sur Entrée, vous serez invité à entrer le code comme indiqué dans la capture d'écran ci-dessous, l'URL pour entrer le code. Sera "https://microsoft.com/devicelogin". Accédons-y.
Entrez (collez) le code affiché sur l'écran PuTTY comme indiqué dans la capture d'écran ci-dessous, puis cliquez sur "Suivant".
Si l'utilisateur que vous souhaitez authentifier ne figure pas dans la liste, cliquez sur Utiliser un autre compte.
Entrez l'utilisateur Azure AD souhaité et cliquez sur Suivant.
Entrez votre mot de passe et cliquez sur Connexion.
La connexion est terminée. Vous pouvez fermer cette fenêtre comme décrit.
Lorsque vous appuyez sur Entrée sur l'écran PuTTY, vous pouvez confirmer que vous pouvez vous connecter à la machine CentOS cible en tant qu'utilisateur Azure AD, comme illustré dans la capture d'écran ci-dessous.
L'authentification par code est requise de la même manière lorsque sudo est effectué par un utilisateur général, mais si la ré-authentification n'est pas requise, vous pouvez ignorer la ré-authentification en éditant le fichier "aad_admins" ci-dessous.
[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
Quelque chose comme ça.
[[email protected]@centos-002-7 ~]$ sudo su -
Last login: Sun May 3 17:28:21 UTC 2020 on pts/0
[root@centos-002-7 ~]#
En prime, étant donné que vous vous authentifiez en tant qu'utilisateur Azure AD, vous pouvez également utiliser l'accès conditionnel pour exiger une authentification multifacteur lors de l'authentification de la connexion SSH. L'image ressemble à ce qui suit.
Tout d'abord, l'authentification par code de l'appareil est effectuée. Entrez le code et cliquez sur Suivant.
Si le compte ne figure pas dans la liste, cliquez sur «Utiliser un autre compte».
Entrez votre nom d'utilisateur et cliquez sur Suivant.
Entrez votre mot de passe et cliquez sur Connexion. Il s'agit de l'authentification à l'aide des informations d'identification normales.
Vous serez invité à ouvrir l'application Microsoft Authenticator et à répondre comme indiqué dans la capture d'écran ci-dessous. En effet, l'utilisateur cible a configuré à l'avance l'application Microsoft Authenticator et est configuré pour utiliser cette application pour l'authentification multifacteur.
La notification suivante sera envoyée au smartphone exécutant l'application Microsoft Authenticator, alors appuyez dessus.
Voulez-vous approuver la connexion? S'affiche, appuyez sur «Approuver».
Maintenant que l'authentification multifacteur est terminée, fermez l'écran ci-dessous et appuyez sur Entrée sur l'écran du côté PuTTY pour terminer la connexion SSH.
Cette fois, afin de connecter en SSH CentOS sur une machine virtuelle Azure à l'aide de l'utilisateur Azure AD, nous utiliserons la méthode de jonction et de réalisation de «Domaine géré d'Azure AD DS» et «Azure Active Directory Authentication» qui est une fonction de prévisualisation publique. Procédure de connexion SSH J'ai essayé de vérifier le fonctionnement de chacun des deux types de modèles.
Comme vous l'avez peut-être remarqué en regardant les deux étapes, il est extrêmement plus facile à configurer en utilisant cette dernière fonction de prévisualisation publique. La raison en est qu'il n'est pas nécessaire de préparer un environnement Azure AD DS en premier lieu, et cela peut être effectué dans Cloud Shell (Azure CLI).
D'autre part, on craint que «Azure Active Directory Authentication», qui est une extension d'Azure VM, ne soit pas une fonction «public preview», c'est-à-dire GA (version authentique).
À ce stade, il peut être plus approprié de choisir de rejoindre Azure AD DS dans un environnement où il existe une règle selon laquelle seule la version GA doit être utilisée pour les environnements de production.
Bien que ce soit une observation encourageante, cette fonction de prévisualisation publique est très pratique car elle peut être utilisée non seulement pour le système d'exploitation Linux mais aussi pour le système d'exploitation Windows. Puisqu'il s'authentifie à l'aide d'utilisateurs Azure AD, il est possible de demander une authentification multifacteur comme indiqué, ce qui améliore la sécurité de l'authentification. De ce point de vue, je ne sais pas quand ce sera, mais personnellement je pense que c'est une fonction qui sera GA.
J'espère que vous trouverez cet article utile.