Prioritizace lokálních účtů vůči doménovým

[tondo123456]

zdravim,

casto logujem na linuxovy server (red hat), na ktorom je aktivovana domenova autentifikacia na prihlasovanie (cez sssd). domenove ucty sa overuju voci windowsovej domene (active directory).

niekedy sa ale stava ze domenovy server (active directory) je spomaleny, neodpoveda... bohuzial nie je v nasej sprave.

problem je, ze ak domenovy server odpoveda pomaly/neodpoveda vobec, neda sa mi na linuxovy server pripojit ani lokalnym uctom.

preto prichadza otazka, ci je mozne nejakym sposobom prioritizovat lokalne ucty?
jednoducho povedane ze ak mam lokalny ucet, napriklad "service_account", sa pri jeho prihlasovani vobec nekontaktoval domenovy server? je to konfiguracne mozne?

dakujem za hociaku odpoved, napad, vysvetlenie

[Reklama]

[James_Scott]

Mam pocit ze priorita by se mohla nastavit poradim sluzeb v

Kód: [Vybrat]

/etc/nsswitch.conf

[_Tomáš_]

/etc/nsswitch.conf určí jedno nebo druhé pokud první nevyhoví (heslo nebo uživatel tam není). Tohle lze ale velice podrobně nastavit přes pam moduly (v /etc/pam.d), jelikož píšeš o sssd, jsou již instalačním scriptem předkonfigurované.

sssd používá cache (případně doporučuji ověřit, že je zapnutá), takže běžné operace jako získání skupíiny a uid uživatele nevytváří dotaz do AD, ale na heslo se musí dotazovat pořád. Aby se mohlo použít lokální heslo (přes shadow) místo dotazu do AD, mělo by stačit upravit:

V souboru /etc/pam.d/password-auth (slouží pro zadávání hesla, když už na serveru máš sezení, např. pro sudo heslo) do sekce password dát tohle:

Kód: [Vybrat]

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so
Nebo v souboru /etc/pam.d/system-auth (slouží pro vzdálené přihlašování třeba přes ssh) opět do sekce password dát to stejné:

Kód: [Vybrat]

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    required      pam_deny.so
Předpoklad je, že existuje lokální účet pro uživatele na OS, tj. že se již přihlásil a je nastaveno automatické vytváření účtů. Píšu z hlavy, tak to zkoušeji opatrně a při zkoušení si vytvoř záložní sezení s otevřeným rootem, ať případně můžeš problémy napravit.

[Miroslav Šilhavý]

Já jen dodám, že z bezpečnostního hlediska není dobrý nápad stejná konta v AD stínovat lokálními účty. Technicky vzato to jsou jiné účty, jen propojené (třeba loginem) a to otevírá potenciál pro průšvihy.

Doporučil bych zřídit si repliku AD na místě. Replikace AD je jednoduchá a funkční, a budete mít vždy při ruce domain controller, který odpoví.

Tak by se to mělo řešit.

[tondo123456]

zdravim,

k jednotlivym odpovediam:

1. nsswitch.conf som pozeral, je tam nakonfugurovane najskor "files" az potom ostatne typy autentifikacie, takze v tom to nebude

2. velmi dakujem, ano, pouziva sa vsade sssd (redhat 6 a 7). konfiguraciu skusim na overit na testovacich serveroch

3. nejde o tienovanie AD uctov lokalnymi uctami. v AD mame ucty "meno.priezvisko", user "abc" existuje len lokalne.
AD uz je v ramci toho isteho atoveho centra, ale problem tam stale pretrvava

suhlasim, ak autentifikacia usera voci domene trva desiatky sekund, skutocnym problemom nie je poradie v akom sa autentifikuju ucty, ale preco odpoved AD trva tak dlho. skor mi ide o teoreticku rovinu - preco sa existencia lokalneho usera "abc" kontroluje aj voci AD, ked je ten user vytvoreny lokalne.

dakujem vsetkym za odpovede, dam vediet ako sa to sprava s upravenou konfiguraciou

[Reklama]

[czechsys]

Protoze muzete mit spatne nastavene SSSD. Protoze kazdy auth system kontroluje podle poradi, zvlast ve chvili, kdy tam neni prepinadlo na ruzne typy auth (login do konzole).