Ubuntu22 AD join

Ubuntu Linux

Sziasztok!

Van egy laptop, amin korábban Win10 volt és tartományba is volt léptetve. A napokban újra lett húzva és lett rárakva egy Ubuntu22. Most azzal kísérletezgetek, hogy a Linuxra is tudjak AD-ba felvett bármilyen userrel bejelentkezni.

A laptopra az sssd-ad sssd-tools realmd adcli adsys telepítve lett, mint előfeltétel.

A realm discover megfelelő eredményt ad vissza. A realm join szintén sikeres volt.

Plusz configként az "Enable home folder creation for domain users" és a "use_fully_qualified_names = False" lett beállítva.

"id testuser"-re először nem adott vissza semmit. De utána rájöttem, hogy AD-ban még nem töröltem a Computers alól a korábbi Win10-es gépet. Ezen kívül még annyi módosítást csináltam a laptopon, hogy felvettem a realmd.conf fileba az "os-name" és "os-version" sorokat. Később meg is jelent az AD-ben a Computers alatt a gép, és az Operating System fülén is már azt írta, hogy Linuxról van szó. + ezt követően az "id testuser"-re is a kívánt eredményt kaptam.  

Egyetlen problémát nem sikerült még megoldanom. Mégpedig a tartományi userrel való bejelentkezést. Úgy próbáltam, hogy átváltottam terminalos bejelentkezésre. A login: után a usernevet még be tudom írni, de a jelszót nem fogadja el. Olyan, mintha nem lenne jó. Viszont egy Win-es gépen kipróbálva be tudok jelentkezni vele.  Nem nagyon találtam rá megoldást eddig. Mi lehet a gond szerintetek?

Előre is köszönöm a javaslatokat!

  • 817 megtekintés

( zeller | 2022. 10. 16., v – 12:26 )

Szerkesztve: 2022. 10. 16., v – 16:50

Az sssd.conf nálam az alábbi:

 

[sssd]
  domains = sajat.domain

  config_file_version = 2
  services = nss, pam
[domain/magnet.bank]
  ad_domain = sajat.domain
  ad_server = dc1.sajat.domain, dc2.sajat.domain
  krb5_realm = SAJAT.DOMAIN
  realmd_tags = manages-system joined-with-adcli
  cache_credentials = True
  dyndns_update = false
  id_provider = ad
  krb5_store_password_if_offline = True
  default_shell = /bin/bash
  ldap_id_mapping = True
  use_fully_qualified_names = False
  fallback_homedir = /home/%u
  access_provider = simple
  simple_allow_groups = linux_ssh_ad_csoport

Nálad tippre a use_fully_qualified_names = True (az a default), akkor elvileg user@sajat.domain formában megy a login, illetve nézd meg a fallback_homedir -t is, mert ott is benne szokott lenni a %d, mint domain.
A pam-auth-update a realm join után "must have", legalább ellenőrzés szintjén, hogy az sssd és az mkhomedir be legeyen állítva.

Én ebből az oldalból indultam ki egyébként: https://computingforgeeks.com/join-ubuntu-debian-to-active-directory-ad…
 

Emlékeim szerint az már új betoldás a posztban... Nekem a linkelt oldalon lévő lista alapján felpakolt csomagok után  realm discover / join / sssd.conf fenti tartalommal történő felülírása és sssd újrarúgása után működik több tucat gépen.

Sikerült megcsinálnom, de egy teljesen más módszerrel, mint a korábbi próbálkozások. Úgy nem nagyon akart összejönni, ezért azt dobtam. A realmd-t és az adsys-t le is szedtem, hogy még véletlenül se legyen semmilyen összeakadás.

Főleg ebből a 2 doksiból merítettem végül az ötleteim jelentős részét:
https://techexpert.tips/ubuntu/ubuntu-kerberos-authentication-active-directory/

https://access.redhat.com/articles/3023951

 

Az sssd-ad és sssd-tools már fent volt korábban. Melléjük jöttek még a továbbiak: heimdal-clients, msktutil, nscd

A krb5.conf-ban nálam lett egy [logging], [domain_realms] és [libdefaults], amelyek alá felvettem a saját igény szerinti beállításokat.

Az nsswitch.conf-ot csak csekkoltam, nekem személy szerint abban nem volt szükségem semmit sem módosítani.

 

Az sssd.conf-ban a services kicsit ki lett bővítve: = nss, pam, ifp, ssh és csak egy [sssd] [pam]  [nss] részem lett.

 

A domaint kivezettem 1 külön xy.intra.conf file-ba az sssd/conf.d/ alá. (Megjegyzem az access_provider maradt benne továbbra is ad. Nem volt kétségem arról, hogy nem az lesz a hiba, hogy az maradt ad és nem simple. )

[domain/XY.INTRA]

;debug_level = 5
 
id_provider = ad
auth_provider = ad
chpass_provider = ad
 
ad_hostname = hostneve.xy.intra
dns_discovery_domain = xy.intra
 
ldap_id_mapping = True
ldap_schema = ad
 
default_shell = /bin/bash
 
access_provider = ad
;ad_access_filter = (|(memberof=CN=xy-team,OU=company,DC=xy,DC=intra)(sAMAccountName=tester))
 
cache_credentials = true
account_cache_expiration = 7
entry_cache_timeout = 14400
 
pwd_expiration_warning = 30
 
ad_gpo_ignore_unreadable = true
krb5_validate = false

 

pam-auth-update esetén fontos, hogy activate mkhomedir legyen megjelölve.

Annyi trükk volt még, hogy kellett egy chmod 0600 /etc/sssd/sssd.conf és a home alá csináltam egy XY.INTRA directory-t, hogy oda tudja létrehozni a belépett AD-s userek könyvtárait.

Természetesen a leírás szerinti kinit és msktutil parancsok kiadása is megvolt nálam.

 

Extraként pedig akár ide is felvehetjük a saját teszt userünket: /etc/sudoers.d/domain_admins
 

Néztem én is az ad access provider-t, de az az ldap-os filterszabály, pláne, ha van n+1 csoport, amit be kell engedni... Nem szép, de legalább ronda és nagyon el...ható, úgyhogy nálam maradt a simple és az ad-s csoportok simple :) felsorolása :-)
 

Nálam a conf fileban nem volt ad_server = sor, azt pótoltam. Jó volt a tipp, a  fallback_homedir -nél is ott volt a %d. Most kiszedtem. dyndns_update = false sem volt, bár jelen esetben szerintem az nem sok vizet zavar. De azért felvettem, megfér ott. :)

Jelenleg ugyanazok a főbb config elemek vannak, mint nálad, egyedüli különbség, hogy access_provider = simple helyett nekem ad a vége. + a simple_allow_groups = sor sem volt, de azt jelenleg csak commentelve vettem fel.

A módosítások után volt egy service restart. Most az sssd status-ra azt írja ki, hogy active (running), de alul jelez pár problémát:

sssd[5268]: Starting up
sssd_be[5269]: Starting up
sssd_nss[5270]: Starting up
sssd_pam[5271]: Starting up
systemd[1]: Started System Security Services Daemon.
sssd_be[5269]: Group Policy Container with DN [cn={D3....5},cn=policies,cn=system,DC=xy,DC=intra] is unreadable or has unreadable or missing attributes. In order to fix this make sure that this AD object has following attributes readable: nTSecurityDescriptor, cn, gPCFileSysPath, gPCMachineExtensionNames, gPCFunctionalityVersion, flags. Alternatively if you do not have access to the server or can not change permissions on this object, you can use option ad_gpo_ignore_unreadable = True which will skip this GPO. See ad_gpo_ignore_unreadable in 'man sssd-ad' for details.

A laptopon 2 AD-s belépési próbálkozás után próbáltam logot nézni, de legutóbb negyed órával előtte írt bele.

Az általad küldött linket nézve nyomtam egy pam-auth-update-et, de az activate mkhomedir rendben volt. Nyomtam még egy realm permit --all -t is és a sudoers.d/domain_admins alá is felvettem a testuser-t

Próbáltam 1 olyat is, hogy GUI-n hozom létre a usert. Ott az enterprise login alatt megjelenik az xy.intra, létre is jön a GUI-s felületen a local user. (de a home alá már nem hozott létre foldert). Ráadásul egyból dobott is egy hibaüzenetet. A details alatt ezt írta:
problem type: crash
Title: sssd crashed with SIGABRT

Csináltam 1 restartot a gépen. Az sssd statusnál feljött egy ilyen sor is:
krb5_child: No credentials cache found (filename: /tmp/krb5cc_....)

Úgy néz ki a journalctl jó lesz. Néztem -f kapcsolóval csak az AD-s login folyamatot, de így is elég nagy infó halmazt dobott ki. Értelmezés után jelentkezem.
 

"Próbáltam 1 olyat is, hogy GUI-n hozom létre a usert. " - Wtf? Vannak az AD-s userek, akikkel lokálisan semmi dolgod. A lokális user létrehozása során nem készül alapból el a home dir, azt a login során a pam_mkhomedir intézi.

 

A kommentezést felejtsd el, emlékeim szerint van arra háklis sssd verzió is...

 

DC: 2016 std,

Comment elhagyása: OK
 

A lokális user létrehozása során nem készül alapból el a home dir

Itt abból indultam ki, hogy régebben néztem mac-en is ezt. Ott létrejött a folder + beállíthattam azt is, hogy az adott AD-s user lehessen az adott gépen local admin.

( fsanyee | 2022. 10. 16., v – 12:47 )

első körben nézd meg a logot, miért nem engedi belépni a usert. ha jó a pw, lehet rossz formátumban van a usernév, nincs engedélyezve, hogy belépjen...

( PeterX | 2022. 10. 17., h – 09:51 )

Szia!

Pár éve (2019) foglalkoztam linux kliensek Windows tartományba léptetésének témájával. A megosztott szkriptet akkor sikeresen alkalmaztam több gép tartományba léptetéséhez. Ha hasznosnak találod használd egészséggel!

A szkriptben és a mellékelt conf fájlokban módosításokat szükséges végrehajtanod felhasználás előtt, mert eredetileg a saját domainemhez készült. Azokat a helyeket ahol módosítanod kell xxxxxx vagy XXXXXX jelöltem (kisbetű/nagybetű számít!).
A szkriptet futtathatóvá kell tenni indítás előtt (bár ezt gondolom te is tudod, de hátha valakinek szükséges ez az infó).

Remélem tudtam segíteni!

https://mega.nz/folder/AZxnWR7L#-4Fp93I0I4C8TAzgrUQsvA

( ricsip v | 2022. 10. 20., cs – 13:41 )

ad_server = dc1.sajat.domain, dc2.sajat.domain

Nem értek a lnuxos AD / LDAP lelkivilágához. De ezt 2022-ben miért kell bedrótozni? Mikor 22 éve DNS SRV recordokkal illene ezt csinálni.

Ezek a bedrótozott beállítások tudják az embert évekkel később megszopatni keményen. Vagy akár az utódot, mivel szokás szerint nincs dokumentálva h. csak DC1 és DC2 van benne a konfigban. Az új IT felelős meg naívan azt hiszi majd DNS SRV lookup-pal meg fogja találni DC3 és DC4-et, mikor DC1 és DC2 nyugdíjba vonul. Aztán jön a meglepetés, h. 10 telephelyen megy flottul, 2-3 helyen meg elhasal "valami miatt".

Dokumentálva van, hogy mi és miért került a konfigokba, ez az egyik. A másik, hogy a DC-ket csak úgy nem csereberéljük, pláne nem a nevet/ip-címet, mert az senkinek sem jó...  Egyébként ott, ahol erre szükség volt, azóta lett DC cserélve, és nem dőlt össze a világ - a kivezetett DC nevét cname-ként megkapta az utódja. És ugye ez a konfig opció csak "hint", hogy milyen névhez tartozó IP-címen keresse a DC-ket...

Nekem muszáj volt kézzel bedrótozni DC-ket LDAP konfigba, mert eleinte nem ismerte az SRV lookup-ot a 3rd party blackbox amin működésre kellett bírni. Aztán meg mikor sikerült meghekkelni, szoptunk vele h. a DC-k össze-vissza vannak a világban (ez még tudott volt), viszont site-aware nem tudtunk a szomszéd switchporton lógó DC-vel beszélni (nem adták hozzá AD-ben a subnet-ünket egy ADsite-hoz sem), hanem ment random a föld túloldalára ahogy esik módon, mindenféle megakadásokat, óriási delay-eket okozva. Aztán meg jött h. a szekusok blokkolták az LDAP portot, és minden DC-re manuálisan kellett hozzáadatnunk az IP rangünket. Aztán mikor jöttek-mentek a DC-k (AD csapat nem beszélt senkivel, kifejezett kérdéseinkre is faszságokat válaszoltak mindig), a DNS SRV meg hirtelen visszaadta az újakat is, amikről persze mi nem tudtunk. Így nem is kértük meg a tűzfal allow-t azokra, ezért elhasalgatott látszólag random időközönként az LDAP. Szóval volt vele szopás bőven, amihez az adott munkahely szervezeti felépítése és idióta munkahelyi arrogáns egymást fúró csapat-légköre is hozzájárult. Hálistennek azóta már eljöttem onnan, és nem nekem kell ezzel se szopnom.