הזוכים בתחרויות הבינלאומיות SSH ו-sudo שוב על הבמה. בהובלת Distinguished Active Directory Conductor

מבחינה היסטורית, הרשאות sudo נשלטו על ידי התוכן של קבצים מ /etc/sudoers.d и ויסודו, והרשאת מפתח בוצעה באמצעות ~/.ssh/authorized_keys. עם זאת, ככל שתשתיות גדלות, יש רצון לנהל את הזכויות הללו באופן מרכזי. כיום עשויות להיות מספר אפשרויות פתרון:

• מערכת ניהול תצורה - שֶׁף, בּוּבָּה, בלתי אפשרי, מלח
• של Active Directory + ssd
• סטיות שונות בצורת סקריפטים ועריכת קבצים ידנית

לדעתי הסובייקטיבית, האפשרות הטובה ביותר לניהול ריכוזי היא עדיין שילוב של Active Directory + ssd. היתרונות של גישה זו הם:

• באמת ספריית משתמשים מרוכזת אחת.
• חלוקת זכויות sudo מסתכם בהוספת משתמש לקבוצת אבטחה ספציפית.
• במקרה של מערכות לינוקס שונות, יש צורך להציג בדיקות נוספות כדי לקבוע את מערכת ההפעלה בעת שימוש במערכות תצורה.

הסוויטה של ​​היום תוקדש במיוחד לחיבור של Active Directory + ssd לניהול זכויות sudo ואחסון ssh מפתחות במאגר יחיד.
אז, האולם קפא בדממה מתוחה, המנצח הרים את שרביטו והתזמורת התכוננה.
בוא נלך.

בהתחשב you
- תחום Active Directory testopf.local ב-Windows Server 2012 R2.
- מארח לינוקס המריץ את Centos 7
- הרשאה מוגדרת באמצעות ssd
שני הפתרונות מבצעים שינויים בסכימה של Active Directory, אז אנחנו בודקים הכל בסביבת בדיקה ורק אז מבצעים שינויים בתשתית העבודה. אני רוצה לציין שכל השינויים ממוקדים ולמעשה מוסיפים רק את התכונות והמחלקות הנדרשות.

פעולה 1: שליטה sudo תפקידים דרך של Active Directory.

כדי להרחיב את המעגל של Active Directory אתה צריך להוריד את המהדורה האחרונה sudo - 1.8.27 נכון להיום. פרק והעתק את הקובץ schema.ActiveDirectory מהספרייה ./doc לבקר התחום. משורת הפקודה עם זכויות מנהל מהספרייה שאליה הקובץ הועתק, הפעל:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(אל תשכח להחליף את הערכים שלך)
פתוח adsiedit.msc והתחבר להקשר ברירת המחדל:
צור חלוקה בשורש התחום מזיע. (הבורגנות טוענת בעקשנות שביחידה זו השד ssd מחפש פריט sudoRole חפצים. עם זאת, לאחר הפעלת ניפוי באגים מפורט ולימוד היומנים, התברר שהחיפוש בוצע בכל עץ הספריות.)
אנו יוצרים את האובייקט הראשון השייך למחלקה בחלוקה sudoRole. ניתן לבחור את השם באופן שרירותי לחלוטין, מכיוון שהוא משמש אך ורק לזיהוי נוח.
בין התכונות הזמינות האפשריות מהרחבת הסכימה, העיקריות שבהן הן הבאות:

• sudoCommand - קובע אילו פקודות מותר להפעיל על המארח.
• sudoHost - קובע לאילו מארחים תפקיד זה חל. ניתן לציין כ הכל, ולמארח בודד בשם. אפשר גם להשתמש במסכה.
• sudoUser - ציין אילו משתמשים רשאים לבצע sudo.
  אם אתה מציין קבוצת אבטחה, הוסף סימן "%" בתחילת השם. אם יש רווחים בשם הקבוצה, אין מה לדאוג. אם לשפוט לפי היומנים, משימת הבריחה מחללים נשלטת על ידי המנגנון ssd.

איור 1. אובייקטים sudoRole בתת-חלוקת sudoers בשורש הספרייה

איור 2. חברות בקבוצות אבטחה המצוינות באובייקטים sudoRole.

ההגדרה הבאה מתבצעת בצד של לינוקס.
בקובץ /etc/nsswitch.conf הוסף את השורה לסוף הקובץ:

sudoers: files sss

בקובץ /etc/sssd/sssd.conf בסעיף [sssd] להוסיף לשירותים sudo

cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo

לאחר כל הפעולות, עליך לנקות את מטמון ה-sssd daemon. עדכונים אוטומטיים מתרחשים כל 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 ולהשתמש בהם בעת הרשאה במארחי לינוקס.

יש להגדיר הרשאה באמצעות sssd.
הוסף את התכונה הנדרשת באמצעות סקריפט PowerShell.
AddsshPublicKeyAttribute.ps1פונקציה New-AttributeID {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Parts=@()
$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])
$oid
}
$schemaPath = (Get-ADRootDSE).schemaNamingContext
$oid = New-AttributeID
$attributes = @{
lDAPDisplayName = 'sshPublicKey';
attributeId = $oid;
oMSyntax = 22;
attributeSyntax = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'מפתח ציבורי של משתמש עבור כניסה ל-SSH';
}

New-ADObject -שם sshPublicKey -Type attributeSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}

לאחר הוספת התכונה, עליך להפעיל מחדש את Active Directory Domain Services.
בואו נעבור למשתמשי Active Directory. אנו ניצור זוג מפתחות לחיבור ssh בכל שיטה הנוחה לך.
אנו משיקים את PuttyGen, לוחצים על כפתור "הפק" ומזיזים בטירוף את העכבר בתוך האזור הריק.
בסיום התהליך נוכל לשמור את המפתחות הציבוריים והפרטיים, להעלות את המפתח הציבורי לתכונת המשתמש של Active Directory וליהנות מהתהליך. עם זאת, יש להשתמש במפתח הציבורי מה-"מפתח ציבורי להדבקה בקובץ Authorized_keys של OpenSSH:".

הוסף את המפתח לתכונת המשתמש.
אפשרות 1 - ממשק משתמש:

אפשרות 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:

1. המשתמש מתחבר לשרת על ידי ציון הכניסה שלו.
2. הדמון sshd, באמצעות סקריפט, מחלץ את ערך המפתח הציבורי מתכונת משתמש ב-Active Directory ומבצע הרשאה באמצעות המפתחות.
3. הדמון sssd מאמת עוד יותר את המשתמש בהתבסס על חברות בקבוצה. תשומת הלב! אם זה לא מוגדר, אז לכל משתמש דומיין תהיה גישה למארח.
4. כשאתה מנסה לעשות sudo, הדמון sssd מחפש תפקידים ב-Active Directory. אם קיימים תפקידים, תכונות המשתמש והחברות בקבוצה נבדקות (אם sudoRoles מוגדר להשתמש בקבוצות משתמשים)

התוצאה.

לפיכך, המפתחות מאוחסנים בתכונות משתמש של Active Directory, הרשאות sudo - באופן דומה, גישה למארחי לינוקס על ידי חשבונות דומיין מתבצעת על ידי בדיקת חברות בקבוצת Active Directory.
הגל האחרון של שרביט המנצח - והאולם קופא בדממה יראת כבוד.

משאבים המשמשים בכתב:

סודו דרך Active Directory
מקשי Ssh דרך Active Directory
סקריפט Powershell, הוספת תכונה ל- Active Directory Schema
שחרור יציב של sudo

מקור: www.habr.com