Geçmişte sudo izinleri, dosyaların içeriğine göre yönetiliyordu. /etc/sudoers.d и visudove anahtar yetkilendirme kullanılarak gerçekleştirildi ~/.ssh/yetkili_anahtarlar. Ancak altyapı büyüdükçe bu hakların merkezi olarak yönetilmesi isteği ortaya çıkıyor. Bugün birkaç çözüm seçeneği olabilir:
- Konfigürasyon Yönetim Sistemi - Şef, Kukla, yanıtlayıcı ', Tuz
- Active Directory + ssd
- Komut dosyaları ve manuel dosya düzenleme biçimindeki çeşitli sapkınlıklar
Benim öznel görüşüme göre, merkezi yönetim için en iyi seçenek hâlâ bir kombinasyondur. Active Directory + ssd. Bu yaklaşımın avantajları şunlardır:
- Gerçekten tek bir merkezi kullanıcı dizini.
- Hakların dağıtımı sudo belirli bir güvenlik grubuna bir kullanıcı eklemeye gelir.
- Çeşitli Linux sistemlerinde, konfigürasyon sistemlerini kullanırken işletim sistemini belirlemek için ek kontroller yapılması gerekli hale gelir.
Bugünün süiti özellikle bağlantıya ayrılacak Active Directory + ssd hak yönetimi için sudo ve depolama ssh Anahtarlar tek bir depoda.
Böylece salon gergin bir sessizlik içinde dondu, şef copunu kaldırdı ve orkestra hazırlandı.
Haydi.
Verilen:
— Aktif Dizin alanı testopf.local Windows Server 2012 R2'de.
— Centos 7 çalıştıran Linux ana bilgisayarı
— Kullanarak yapılandırılmış yetkilendirme ssd
Her iki çözüm de şemada değişiklik yapar Active Directoryyani her şeyi bir test ortamında kontrol ediyoruz ve ancak bundan sonra çalışan altyapıda değişiklikler yapıyoruz. Tüm değişikliklerin hedeflendiğini ve aslında yalnızca gerekli nitelikleri ve sınıfları eklediğini belirtmek isterim.
Eylem 1: kontrol sudo aracılığıyla roller Active Directory.
Devreyi genişletmek için Active Directory en son sürümü indirmeniz gerekiyor — 1.8.27 bugün itibariyle. Dosyayı paketinden çıkarın ve kopyalayın schema.ActiveDirectory ./doc dizininden etki alanı denetleyicisine. Dosyanın kopyalandığı dizindeki yönetici haklarına sahip komut satırından şunu çalıştırın:
ldifde -i -f schema.ActiveDirectory -c dc=X dc=testopf,dc=local
(Değerlerinizi değiştirmeyi unutmayın)
Açık adsiedit.msc ve varsayılan içeriğe bağlanın:
Alan adının kökünde bir bölüm oluşturun sudoers. (Burjuvazi inatla şeytanın bu birimde olduğunu iddia ediyor.) ssd bir öğeyi arar sudoRole nesneler. Ancak ayrıntılı hata ayıklamayı açtıktan ve günlükleri inceledikten sonra aramanın tüm dizin ağacında yapıldığı ortaya çıktı.)
Bölümdeki sınıfa ait ilk nesneyi oluşturuyoruz sudoRole. Ad, yalnızca uygun tanımlamaya hizmet ettiği için kesinlikle keyfi olarak seçilebilir.
Şema uzantısındaki olası özellikler arasında başlıcaları şunlardır:
- sudoKomutu — Ana bilgisayarda hangi komutların yürütülmesine izin verildiğini belirler.
- sudoHost — bu rolün hangi ana bilgisayarlara uygulanacağını belirler. Olarak belirtilebilir HEPSİve bireysel bir ana bilgisayar için ada göre. Maske kullanmak da mümkündür.
- sudoKullanıcı — hangi kullanıcıların yürütmesine izin verildiğini belirtin sudo.
Bir güvenlik grubu belirtirseniz adının başına “%” işareti ekleyin. Grup adında boşluk varsa endişelenecek bir durum yok. Kayıtlara bakılırsa boşluklardan kaçma görevi mekanizma tarafından üstleniliyor ssd.
Şekil 1. dizinin kökündeki sudoers alt bölümündeki sudoRole nesneleri
Şekil 2. SudoRole nesnelerinde belirtilen güvenlik gruplarına üyelik.
Linux tarafında aşağıdaki kurulum yapılır.
Dosyada /etc/nsswitch.conf satırı dosyanın sonuna ekleyin:
sudoers: files sssDosyada /etc/sssd/sssd.conf kısımda [sssd] hizmetlere ekle sudo
cat /etc/sssd/sssd.conf | grep services
services = nss, pam, sudo
Tüm işlemlerden sonra sssd daemon önbelleğini temizlemeniz gerekir. Otomatik güncellemeler her 6 saatte bir gerçekleşiyor ama şimdi istediğimiz halde neden bu kadar bekleyelim ki?
sss_cache -EÇoğu zaman önbelleği temizlemenin işe yaramadığı görülür. Daha sonra servisi durdurup veritabanını temizliyoruz ve servisi başlatıyoruz.
service sssd stop
rm -rf /var/lib/sss/db/*
service sssd start
İlk kullanıcı olarak bağlanıyoruz ve sudo altında onun için nelerin mevcut olduğunu kontrol ediyoruz:
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/catAynısını ikinci kullanıcımız için de yapıyoruz:
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
Bu yaklaşım, farklı kullanıcı grupları için sudo rollerini merkezi olarak tanımlamanıza olanak tanır.
Active Directory'de ssh anahtarlarını saklama ve kullanma
Şemanın biraz genişletilmesiyle, ssh anahtarlarını Active Directory kullanıcı özniteliklerinde saklamak ve bunları Linux ana bilgisayarlarında yetkilendirme yaparken kullanmak mümkündür.
Sssd üzerinden yetkilendirme yapılandırılmalıdır.
Bir PowerShell betiği kullanarak gerekli özniteliği ekleyin.
AddsshPublicKeyAttribute.ps1İşlev Yeni-Öznitelik Kimliği {
$Prefix="1.2.840.113556.1.8000.2554"
$GUID=[System.Guid]::NewGuid().ToString()
$Parçalar=@()
$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 = Yeni Özellik Kimliği
$öznitelikler = @{
lDAPDisplayName = 'sshPublicKey';
nitelikKimliği = $oid;
oMSdizimi = 22;
nitelikSözdizimi = "2.5.5.5";
isSingleValued = $true;
adminDescription = 'SSH girişi için Kullanıcı Genel anahtarı';
}
New-ADObject -Name sshPublicKey -Type featureSchema -Path $schemapath -OtherAttributes $attributes
$userSchema = get-adobject -SearchBase $schemapath -Filter 'name -eq "user"'
$userSchema | Set-ADObject -Add @{mayContain = 'sshPublicKey'}
Özniteliği ekledikten sonra Active Directory Etki Alanı Hizmetlerini yeniden başlatmanız gerekir.
Active Directory kullanıcılarına geçelim. Size uygun herhangi bir yöntemi kullanarak ssh bağlantısı için bir anahtar çifti oluşturacağız.
PuttyGen'i başlatıyoruz, "Oluştur" düğmesine basıyoruz ve fareyi çılgınca boş alan içinde hareket ettiriyoruz.
İşlem tamamlandıktan sonra genel ve özel anahtarları kaydedip, ortak anahtarı Active Directory kullanıcı özelliğine yükleyebilir ve sürecin tadını çıkarabiliriz. Ancak genel anahtarın "OpenSSH yetkili_anahtarlar dosyasına yapıştırmak için genel anahtar:".
Anahtarı kullanıcı özelliğine ekleyin.
Seçenek 1 - GUI:
Seçenek 2 - PowerShell:
get-aduser user1 | set-aduser -add @{sshPublicKey = 'AAAAB...XAVnX9ZRJJ0p/Q=='}
Şu anda elimizde: sshPublicKey niteliği doldurulmuş bir kullanıcı, anahtarları kullanarak yetkilendirme için yapılandırılmış bir Putty istemcisi var. Geriye küçük bir nokta kalıyor: sshd arka plan programının, ihtiyacımız olan genel anahtarı kullanıcının özelliklerinden çıkarmaya nasıl zorlanacağı. Burjuva internette bulunan küçük bir komut dosyası bununla başarılı bir şekilde başa çıkabilir.
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'Üzerindeki izinleri root için 0500 olarak ayarladık.
chmod 0500 /usr/local/bin/fetchSSHKeysFromLDAP
Bu örnekte dizine bağlanmak için bir yönetici hesabı kullanılıyor. Savaş koşullarında, asgari haklara sahip ayrı bir hesap bulunmalıdır.
Kişisel olarak, belirlenen haklara rağmen, şifrenin senaryoda saf haliyle bulunması beni çok şaşırttı.
Çözüm seçeneği:
- Şifreyi ayrı bir dosyaya kaydediyorum:
echo -n Supersecretpassword > /usr/local/etc/secretpass - Dosya izinlerini root için 0500 olarak ayarladım
chmod 0500 /usr/local/etc/secretpass - Ldapsearch başlatma parametrelerini değiştirme: parametre -w süperGizliŞifre onu şu şekilde değiştiriyorum -y /usr/yerel/etc/gizligeçiş
Bugünkü paketimizin son akoru sshd_config'i düzenlemek
cat /etc/ssh/sshd_config | egrep -v -E "#|^$" | grep -E "AuthorizedKeysCommand|PubkeyAuthe"
PubkeyAuthentication yes
AuthorizedKeysCommand /usr/local/bin/fetchSSHKeysFromLDAP
AuthorizedKeysCommandUser root
Sonuç olarak, ssh istemcisinde anahtar yetkilendirmenin yapılandırılmış olduğu aşağıdaki sırayı elde ederiz:
- Kullanıcı, giriş bilgilerini belirterek sunucuya bağlanır.
- Sshd arka plan programı, bir komut dosyası aracılığıyla, genel anahtar değerini Active Directory'deki bir kullanıcı özelliğinden çıkarır ve anahtarları kullanarak yetkilendirme gerçekleştirir.
- Sssd arka plan programı ayrıca grup üyeliğine dayalı olarak kullanıcının kimliğini doğrular. Dikkat! Bu yapılandırılmazsa herhangi bir etki alanı kullanıcısı ana makineye erişebilir.
- Sudo yapmayı denediğinizde, sssd arka plan programı Active Directory'de rolleri arar. Roller mevcutsa kullanıcının nitelikleri ve grup üyeliği kontrol edilir (sudoRoles kullanıcı gruplarını kullanacak şekilde yapılandırılmışsa)
Özet.
Böylece, anahtarlar Active Directory kullanıcı özniteliklerinde, sudo izinlerinde saklanır - benzer şekilde, Linux ana bilgisayarlarına etki alanı hesapları tarafından erişim, Active Directory grubundaki üyelik kontrol edilerek gerçekleştirilir.
Orkestra şefinin copunun son dalgası ve salon saygılı bir sessizlik içinde donuyor.
Yazılı olarak kullanılan kaynaklar:
Kaynak: habr.com