Ιστορικά, τα δικαιώματα sudo διέπονταν από τα περιεχόμενα των αρχείων από /etc/sudoers.d и visudo, και η εξουσιοδότηση κλειδιού πραγματοποιήθηκε χρησιμοποιώντας ~/.ssh/authorized_keys. Ωστόσο, καθώς οι υποδομές μεγαλώνουν, υπάρχει η επιθυμία να διαχειρίζονται αυτά τα δικαιώματα κεντρικά. Σήμερα μπορεί να υπάρχουν πολλές επιλογές λύσης:
- Σύστημα Διαχείρισης Διαμόρφωσης - Chef, μαριονέτα, Πιθανό, Αλάτι
- Active Directory + SSD
- Διάφορες παραμορφώσεις με τη μορφή σεναρίων και χειροκίνητης επεξεργασίας αρχείων
Κατά την υποκειμενική μου γνώμη, η καλύτερη επιλογή για κεντρική διαχείριση εξακολουθεί να είναι ένας συνδυασμός Active Directory + SSD. Τα πλεονεκτήματα αυτής της προσέγγισης είναι:
- Πραγματικά ένας μόνο κεντρικός κατάλογος χρηστών.
- Κατανομή δικαιωμάτων sudo καταλήγει στην προσθήκη ενός χρήστη σε μια συγκεκριμένη ομάδα ασφαλείας.
- Στην περίπτωση διαφόρων συστημάτων Linux, καθίσταται απαραίτητο να εισαχθούν πρόσθετοι έλεγχοι για τον προσδιορισμό του λειτουργικού συστήματος κατά τη χρήση συστημάτων διαμόρφωσης.
Η σημερινή σουίτα θα είναι αφιερωμένη ειδικά στη σύνδεση Active Directory + SSD για τη διαχείριση δικαιωμάτων sudo και αποθήκευση ssh κλειδιά σε ένα μόνο αποθετήριο.
Έτσι, η αίθουσα πάγωσε σε τεταμένη σιωπή, ο μαέστρος σήκωσε τη σκυτάλη και η ορχήστρα ετοιμάστηκε.
Πηγαίνω.
Δεδομένος:
— Τομέας Active Directory testopf.τοπικός στον Windows Server 2012 R2.
— Κεντρικός υπολογιστής Linux που εκτελεί το Centos 7
— Διαμόρφωση εξουσιοδότησης χρησιμοποιώντας SSD
Και οι δύο λύσεις κάνουν αλλαγές στο σχήμα Active Directory, επομένως ελέγχουμε τα πάντα σε ένα δοκιμαστικό περιβάλλον και μόνο τότε κάνουμε αλλαγές στην υποδομή εργασίας. Θα ήθελα να σημειώσω ότι όλες οι αλλαγές είναι στοχευμένες και, στην πραγματικότητα, προσθέτουν μόνο τα απαραίτητα χαρακτηριστικά και κλάσεις.
Δράση 1: έλεγχος sudo ρόλους μέσω Active Directory.
Για επέκταση του κυκλώματος Active Directory πρέπει να κατεβάσετε την πιο πρόσφατη έκδοση — 1.8.27 από σήμερα. Αποσυσκευάστε και αντιγράψτε το αρχείο schema.ActiveDirectory από τον κατάλογο ./doc στον ελεγκτή τομέα. Από τη γραμμή εντολών με δικαιώματα διαχειριστή από τον κατάλογο όπου αντιγράφηκε το αρχείο, εκτελέστε:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Μην ξεχάσετε να αντικαταστήσετε τις αξίες σας)
Ανοίξτε adsiedit.msc και συνδεθείτε στο προεπιλεγμένο περιβάλλον:
Δημιουργήστε μια διαίρεση στη ρίζα του τομέα sudoers. (Η αστική τάξη ισχυρίζεται πεισματικά ότι σε αυτή τη μονάδα βρίσκεται ο δαίμονας SSD αναζητά ένα αντικείμενο sudoRole αντικείμενα. Ωστόσο, μετά την ενεργοποίηση του λεπτομερούς εντοπισμού σφαλμάτων και τη μελέτη των αρχείων καταγραφής, αποκαλύφθηκε ότι η αναζήτηση πραγματοποιήθηκε σε ολόκληρο το δέντρο καταλόγου.)
Δημιουργούμε το πρώτο αντικείμενο που ανήκει στην κλάση στη διαίρεση sudoRole. Το όνομα μπορεί να επιλεγεί απολύτως αυθαίρετα, καθώς χρησιμεύει αποκλειστικά για εύκολη αναγνώριση.
Μεταξύ των πιθανών διαθέσιμων χαρακτηριστικών από την επέκταση σχήματος, τα κύρια είναι τα ακόλουθα:
- sudoCommand — καθορίζει ποιες εντολές επιτρέπεται να εκτελούνται στον κεντρικό υπολογιστή.
- sudoHost — καθορίζει σε ποιους κεντρικούς υπολογιστές ισχύει αυτός ο ρόλος. Μπορεί να οριστεί ως ΌΛΟΙ, και για έναν μεμονωμένο κεντρικό υπολογιστή με όνομα. Είναι επίσης δυνατή η χρήση μάσκας.
- sudoUser — υποδείξτε ποιους χρήστες επιτρέπεται να εκτελέσουν sudo.
Εάν καθορίσετε μια ομάδα ασφαλείας, προσθέστε ένα σύμβολο "%" στην αρχή του ονόματος. Εάν υπάρχουν κενά στο όνομα της ομάδας, δεν υπάρχει τίποτα να ανησυχείτε. Κρίνοντας από τα κούτσουρα, το έργο της διαφυγής χώρων αναλαμβάνει ο μηχανισμός SSD.
Εικ. 1. αντικείμενα sudoRole στην υποδιαίρεση sudoers στη ρίζα του καταλόγου
Εικόνα 2. Συμμετοχή σε ομάδες ασφαλείας που καθορίζονται στα αντικείμενα sudoRole.
Η ακόλουθη ρύθμιση γίνεται στην πλευρά του Linux.
Στο αρχείο /etc/nsswitch.conf προσθέστε τη γραμμή στο τέλος του αρχείου:
sudoers: files sssΣτο αρχείο /etc/sssd/sssd.conf στο τμήμα [sssd] προσθήκη στις υπηρεσίες sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Μετά από όλες τις λειτουργίες, πρέπει να διαγράψετε την προσωρινή μνήμη δαίμονα sssd. Οι αυτόματες ενημερώσεις γίνονται κάθε 6 ώρες, αλλά γιατί να περιμένουμε τόσο πολύ όταν το θέλουμε τώρα;
sss_cache -EΣυχνά συμβαίνει ότι η εκκαθάριση της προσωρινής μνήμης δεν βοηθά. Στη συνέχεια διακόπτουμε την υπηρεσία, καθαρίζουμε τη βάση δεδομένων και ξεκινάμε την υπηρεσία.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
Συνδεόμαστε ως ο πρώτος χρήστης και ελέγχουμε τι είναι διαθέσιμο σε αυτόν στο 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/catΚάνουμε το ίδιο με τον δεύτερο χρήστη μας:
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
Αυτή η προσέγγιση σάς επιτρέπει να ορίζετε κεντρικά τους ρόλους sudo για διαφορετικές ομάδες χρηστών.
Αποθήκευση και χρήση κλειδιών ssh στην υπηρεσία καταλόγου Active Directory
Με μια μικρή επέκταση του σχήματος, είναι δυνατή η αποθήκευση κλειδιών ssh σε χαρακτηριστικά χρήστη Active Directory και η χρήση τους κατά την εξουσιοδότηση σε κεντρικούς υπολογιστές Linux.
Πρέπει να ρυθμιστεί η εξουσιοδότηση μέσω sssd.
Προσθέστε το απαιτούμενο χαρακτηριστικό χρησιμοποιώντας μια δέσμη ενεργειών PowerShell.
AddsshPublicKeyAttribute.ps1Συνάρτηση New-AttributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Parts=@()
$Parts+=[UIint64]::Parse($guid.SubString(0,4),"AllowHexSpecifier")
$Parts+=[UIint64]::Parse($guid.SubString(4,4),"AllowHexSpecifier")
$Parts+=[UIint64]::Parse($guid.SubString(9,4),"AllowHexSpecifier")
$Parts+=[UIint64]::Parse($guid.SubString(14,4),"AllowHexSpecifier")
$Parts+=[UIint64]::Parse($guid.SubString(19,4),"AllowHexSpecifier")
$Parts+=[UIint64]::Parse($guid.SubString(24,6),"AllowHexSpecifier")
$Parts+=[UIint64]::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])
$oid
}
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$oid = Αναγνωριστικό νέου χαρακτηριστικού
$attributes = @{
lDAPDisplayName = 'sshPublicKey';
χαρακτηριστικόId = $oid;
oMSyntax = 22;
χαρακτηριστικόSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'Δημόσιο κλειδί χρήστη για σύνδεση SSH';
}
New-ADObject -Name sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Φίλτρο 'όνομα -eq "χρήστης"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Αφού προσθέσετε το χαρακτηριστικό, πρέπει να επανεκκινήσετε τις υπηρεσίες τομέα Active Directory.
Ας περάσουμε στους χρήστες της υπηρεσίας καταλόγου Active Directory. Θα δημιουργήσουμε ένα ζεύγος κλειδιών για σύνδεση ssh χρησιμοποιώντας οποιαδήποτε μέθοδο είναι κατάλληλη για εσάς.
Εκκινούμε το PuttyGen, πατάμε το κουμπί «Δημιουργία» και μετακινούμε μανιωδώς το ποντίκι στην κενή περιοχή.
Με την ολοκλήρωση της διαδικασίας, μπορούμε να αποθηκεύσουμε το δημόσιο και ιδιωτικό κλειδί, να ανεβάσουμε το δημόσιο κλειδί στο χαρακτηριστικό χρήστη Active Directory και να απολαύσουμε τη διαδικασία. Ωστόσο, το δημόσιο κλειδί πρέπει να χρησιμοποιείται από το "Δημόσιο κλειδί για επικόλληση στο αρχείο OpenSSH authorized_keys:".
Προσθέστε το κλειδί στο χαρακτηριστικό χρήστη.
Επιλογή 1 - GUI:
Επιλογή 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Έτσι, έχουμε αυτήν τη στιγμή: έναν χρήστη με συμπληρωμένο το χαρακτηριστικό sshPublicKey, έναν διαμορφωμένο πελάτη Putty για εξουσιοδότηση με χρήση κλειδιών. Παραμένει ένα μικρό σημείο: πώς να αναγκάσουμε τον δαίμονα sshd να εξαγάγει το δημόσιο κλειδί που χρειαζόμαστε από τα χαρακτηριστικά του χρήστη. Ένα μικρό σενάριο που βρέθηκε στο αστικό Διαδίκτυο μπορεί να το αντιμετωπίσει με επιτυχία.
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'Ορίσαμε τα δικαιώματα σε αυτό στο 0500 για root.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Σε αυτό το παράδειγμα, ένας λογαριασμός διαχειριστή χρησιμοποιείται για σύνδεση στον κατάλογο. Σε συνθήκες μάχης πρέπει να υπάρχει ξεχωριστός λογαριασμός με ένα ελάχιστο σύνολο δικαιωμάτων.
Προσωπικά ήμουν πολύ μπερδεμένος από τη στιγμή του κωδικού πρόσβασης στην καθαρή του μορφή στο σενάριο, παρά τα δικαιώματα που έχουν οριστεί.
Επιλογή λύσης:
- Αποθηκεύω τον κωδικό πρόσβασης σε ξεχωριστό αρχείο:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Ρύθμισα δικαιώματα αρχείων σε 0500 για root
chmod 0500 /usr/local/etc/secretpass - Αλλαγή παραμέτρων εκκίνησης ldapsearch: παράμετρος -w superSecretPassword Το αλλάζω σε -y /usr/local/etc/secretpass
Η τελευταία συγχορδία στη σημερινή σουίτα είναι η επεξεργασία του sshd_config
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Ως αποτέλεσμα, λαμβάνουμε την ακόλουθη σειρά με εξουσιοδότηση κλειδιού ρυθμισμένη στον πελάτη ssh:
- Ο χρήστης συνδέεται με τον διακομιστή υποδεικνύοντας τη σύνδεσή του.
- Ο δαίμονας sshd, μέσω ενός σεναρίου, εξάγει την τιμή του δημόσιου κλειδιού από ένα χαρακτηριστικό χρήστη στην υπηρεσία καταλόγου Active Directory και εκτελεί εξουσιοδότηση χρησιμοποιώντας τα κλειδιά.
- Ο δαίμονας sssd επαληθεύει περαιτέρω την ταυτότητα του χρήστη βάσει της ιδιότητας μέλους ομάδας. Προσοχή! Εάν αυτό δεν έχει ρυθμιστεί, τότε οποιοσδήποτε χρήστης τομέα θα έχει πρόσβαση στον κεντρικό υπολογιστή.
- Όταν προσπαθείτε να κάνετε sudo, ο δαίμονας sssd αναζητά ρόλους στην υπηρεσία καταλόγου Active Directory. Εάν υπάρχουν ρόλοι, ελέγχονται τα χαρακτηριστικά του χρήστη και η ιδιότητα μέλους ομάδας (εάν το sudoRoles έχει ρυθμιστεί να χρησιμοποιεί ομάδες χρηστών)
Περίληψη.
Έτσι, τα κλειδιά αποθηκεύονται σε χαρακτηριστικά χρήστη Active Directory, δικαιώματα sudo - παρομοίως, η πρόσβαση σε κεντρικούς υπολογιστές Linux από λογαριασμούς τομέα πραγματοποιείται ελέγχοντας τη συμμετοχή στην ομάδα Active Directory.
Το τελευταίο κύμα της σκυτάλης του μαέστρου - και η αίθουσα παγώνει σε ευλαβική σιωπή.
Πόροι που χρησιμοποιούνται γραπτώς:
Πηγή: www.habr.com