Historiquement, les autorisations sudo étaient régies par le contenu des fichiers de /etc/sudoers.d и visa, et l'autorisation de clé a été effectuée à l'aide de ~ / .ssh / clés_autorisées. Cependant, à mesure que les infrastructures se développent, il existe une volonté de gérer ces droits de manière centralisée. Aujourd'hui, il peut y avoir plusieurs options de solution :
- Système de gestion de configuration - Chef, Fantoche, Ansible, Sel
- active Directory + ssd
- Diverses perversions sous forme de scripts et d'édition manuelle de fichiers
À mon avis subjectif, la meilleure option pour une gestion centralisée reste une combinaison active Directory + ssd. Les avantages de cette approche sont :
- Vraiment un seul annuaire d’utilisateurs centralisé.
- Répartition des droits sudo revient à ajouter un utilisateur à un groupe de sécurité spécifique.
- Dans le cas de différents systèmes Linux, il devient nécessaire d'introduire des contrôles supplémentaires pour déterminer le système d'exploitation lors de l'utilisation de systèmes de configuration.
La suite d'aujourd'hui sera dédiée spécifiquement à la connexion active Directory + ssd pour la gestion des droits sudo et stockage ssh clés dans un seul référentiel.
Ainsi, la salle s'est figée dans un silence tendu, le chef d'orchestre a levé sa baguette et l'orchestre s'est préparé.
Allez.
donné:
— Domaine Active Directory testopf.local sur Windows Serveur 2012 R2.
— Hôte Linux exécutant Centos 7
— Autorisation configurée à l'aide ssd
Les deux solutions apportent des modifications au schéma active Directory, nous vérifions donc tout dans un environnement de test et apportons ensuite des modifications à l'infrastructure de travail. Je voudrais noter que tous les changements sont ciblés et, en fait, n'ajoutent que les attributs et classes nécessaires.
Action 1 : contrôler sudo rôles à travers active Directory.
Pour élargir le circuit active Directory vous devez télécharger la dernière version — 1.8.27 à compter d'aujourd'hui. Décompressez et copiez le fichier schéma.ActiveDirectory du répertoire ./doc vers le contrôleur de domaine. Depuis la ligne de commande avec les droits d'administrateur du répertoire où le fichier a été copié, exécutez :
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(N'oubliez pas de remplacer vos valeurs)
Ouvrir adsiedit.msc et connectez-vous au contexte par défaut :
Créer une division à la racine du domaine sueurs. (La bourgeoisie prétend obstinément que c'est dans cette unité que le démon ssd recherche un article sudoRôle objets. Cependant, après avoir activé le débogage détaillé et étudié les journaux, il a été révélé que la recherche avait été effectuée dans toute l'arborescence des répertoires.)
On crée le premier objet appartenant à la classe dans la division sudoRôle. Le nom peut être choisi de manière absolument arbitraire, car il sert uniquement à une identification pratique.
Parmi les attributs possibles disponibles depuis l’extension de schéma, les principaux sont les suivants :
- Commande sudo — détermine quelles commandes peuvent être exécutées sur l'hôte.
- sudoHôte — détermine à quels hôtes ce rôle s'applique. Peut être spécifié comme TOUTES, et pour un hôte individuel par son nom. Il est également possible d'utiliser un masque.
- sudoUtilisateur — indiquer quels utilisateurs sont autorisés à exécuter sudo.
Si vous spécifiez un groupe de sécurité, ajoutez un signe « % » au début du nom. S'il y a des espaces dans le nom du groupe, il n'y a pas de quoi s'inquiéter. À en juger par les journaux, la tâche d'échapper aux espaces est prise en charge par le mécanisme ssd.
Fig 1. Objets sudoRole dans la subdivision sudoers à la racine du répertoire
Figure 2. Appartenance aux groupes de sécurité spécifiés dans les objets sudoRole.
La configuration suivante est effectuée côté Linux.
En fichier /etc/nsswitch.conf ajoutez la ligne à la fin du fichier :
sudoers: files sssEn fichier /etc/sssd/sssd.conf dans la section [ssd] ajouter aux services sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Après toutes les opérations, vous devez vider le cache du démon sssd. Les mises à jour automatiques ont lieu toutes les 6 heures, mais pourquoi devrions-nous attendre si longtemps alors que nous le voulons maintenant ?
sss_cache -EIl arrive souvent que vider le cache n’aide pas. Ensuite, nous arrêtons le service, nettoyons la base de données et démarrons le service.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Nous nous connectons en tant que premier utilisateur et vérifions ce qui lui est disponible sous sudo :
su user1
[user1@testsshad log]$ id
uid=1109801141(user1) gid=1109800513(domain users) groups=1109800513(domain users),1109801132(admins_)
[user1@testsshad log]$ sudo -l
[sudo] password for user1:
Matching Defaults entries for user1 on testsshad:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin:/bin:/usr/sbin:/usr/bin
User user1 may run the following commands on testsshad:
(root) /usr/bin/ls, /usr/bin/catNous faisons la même chose avec notre deuxième utilisateur :
su user2
[user2@testsshad log]$ id
uid=1109801142(user2) gid=1109800513(domain users) groups=1109800513(domain users),1109801138(sudo_root)
[user2@testsshad log]$ sudo -l
Matching Defaults entries for user2 on testsshad:
!visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin,
env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS",
env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE",
env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY",
secure_path=/sbin:/bin:/usr/sbin:/usr/bin
User user2 may run the following commands on testsshad:
(root) ALL
Cette approche vous permet de définir de manière centralisée les rôles sudo pour différents groupes d'utilisateurs.
Stockage et utilisation des clés ssh dans Active Directory
Avec une légère extension du schéma, il est possible de stocker les clés ssh dans les attributs utilisateur Active Directory et de les utiliser lors de l'autorisation sur les hôtes Linux.
L'autorisation via SSD doit être configurée.
Ajoutez l'attribut requis à l'aide d'un script PowerShell.
AjouteshPublicKeyAttribute.ps1Fonction New-AttributeID {
$Préfixe="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid] ::NewGuid().ToString()
$Pièces=@()
$Parts+=[UInt64]::Parse($guid.SubString(0,4),« AllowHexSpecifier »)
$Parts+=[UInt64]::Parse($guid.SubString(4,4),« AllowHexSpecifier »)
$Parts+=[UInt64]::Parse($guid.SubString(9,4),« AllowHexSpecifier »)
$Parts+=[UInt64]::Parse($guid.SubString(14,4),« AllowHexSpecifier »)
$Parts+=[UInt64]::Parse($guid.SubString(19,4),« AllowHexSpecifier »)
$Parts+=[UInt64]::Parse($guid.SubString(24,6),« AllowHexSpecifier »)
$Parts+=[UInt64]::Parse($guid.SubString(30,6),« AllowHexSpecifier »)
$oid=[String]::Format(«{0}.{1}.{2}.{3}.{4}.{5}.{6}.{7}»,$prefix,$Parts[0],
$Parts[1],$Parts[2],$Parts[3],$Parts[4],$Parts[5],$Parts[6])
$oïde
}
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$oid = Nouvel ID d'attribut
$attributs = @{
lDAPDisplayName = 'sshPublicKey';
attributId = $oid;
oMSyntaxe = 22 ;
attributSyntaxe = "2.5.5.5" ;
isSingleValued = $true ;
adminDescription = 'Clé publique utilisateur pour la connexion SSH';
}
New-ADObject -Nom sshPublicKey -Type attributSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'nom -eq "utilisateur"'
$schémautilisateur | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Après avoir ajouté l'attribut, vous devez redémarrer les services de domaine Active Directory.
Passons aux utilisateurs Active Directory. Nous générerons une paire de clés pour la connexion SSH en utilisant n'importe quelle méthode qui vous convient.
Nous lançons PuttyGen, appuyons sur le bouton « Générer » et déplaçons frénétiquement la souris dans la zone vide.
Une fois le processus terminé, nous pouvons enregistrer les clés publiques et privées, télécharger la clé publique dans l'attribut utilisateur Active Directory et profiter du processus. Cependant, la clé publique doit être utilisée à partir du "Clé publique à coller dans le fichier Authorized_keys d'OpenSSH :«.
Ajoutez la clé à l'attribut utilisateur.
Option 1 - Interface graphique :
Option 2 - PowerShell :
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Nous avons donc actuellement : un utilisateur avec l'attribut sshPublicKey renseigné, un client Putty configuré pour l'autorisation à l'aide de clés. Reste un petit point : comment forcer le démon sshd à extraire la clé publique dont nous avons besoin des attributs de l'utilisateur. Un petit script trouvé sur l'Internet bourgeois peut y faire face avec succès.
cat /usr/local/bin/fetchSSHKeysFromLDAP
#!/bin/sh
ldapsearch -h testmdt.testopf.local -xb "dc=testopf,dc=local" '(sAMAccountName='"${1%@*}"')' -D [email protected] -w superSecretPassword 'sshPublicKey' | sed -n '/^ /{H;d};/sshPublicKey:/x;$g;s/n *//g;s/sshPublicKey: //gp'Nous définissons les autorisations sur 0500 pour root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Dans cet exemple, un compte administrateur est utilisé pour se lier au répertoire. Dans des conditions de combat, il doit y avoir un compte séparé avec un minimum de droits.
Personnellement, j'ai été très confus par le moment du mot de passe sous sa forme pure dans le script, malgré les droits définis.
Option de solution:
- J'enregistre le mot de passe dans un fichier séparé :
echo -n Supersecretpassword > /usr/local/etc/secretpass - J'ai défini les autorisations de fichiers sur 0500 pour root
chmod 0500 /usr/local/etc/secretpass - Modification des paramètres de lancement de ldapsearch : paramètre -w mot de passe superSecret je le change en -y /usr/local/etc/secretpass
L'accord final de la suite d'aujourd'hui est l'édition de sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
En conséquence, nous obtenons la séquence suivante avec l'autorisation de clé configurée dans le client ssh :
- L'utilisateur se connecte au serveur en indiquant son login.
- Le démon sshd, via un script, extrait la valeur de la clé publique d'un attribut utilisateur dans Active Directory et effectue l'autorisation à l'aide des clés.
- Le démon sssd authentifie en outre l'utilisateur en fonction de son appartenance à un groupe. Attention! Si cela n'est pas configuré, tout utilisateur du domaine aura accès à l'hôte.
- Lorsque vous essayez de sudo, le démon sssd recherche les rôles dans Active Directory. Si des rôles sont présents, les attributs de l'utilisateur et l'appartenance au groupe sont vérifiés (si sudoRoles est configuré pour utiliser des groupes d'utilisateurs)
Résumé.
Ainsi, les clés sont stockées dans les attributs utilisateur Active Directory, les autorisations sudo - de même, l'accès aux hôtes Linux par comptes de domaine s'effectue en vérifiant l'appartenance au groupe Active Directory.
Le dernier coup de baguette du chef d'orchestre - et la salle se fige dans un silence respectueux.
Ressources utilisées par écrit :
Source: habr.com