Puncte:1

Linux: conversia de la NIS la autentificare AD, cum să asociem vechiul UID/GID cu utilizatorii „noi”?

drapel cn

Context: Organizația noastră a folosit NIS de peste 20 de ani pentru autentificarea UNIX/Linux, continuând până în prezent. Windows și Active Directory au apărut în organizația noastră cu aproximativ 16 ani în urmă, dar AD nu a fost niciodată folosit pentru autentificarea Linux (folosind doar RHEL/CentOS și Ubuntu Linux acum, toate celelalte *nix au căzut pe margine.) Deci, pe toate resursele noastre Linux, încă folosim intervale UID/GID tradiționale pentru fișierele utilizatorilor.

Acum, conducerea a dictat în sfârșit că trebuie să trecem la AD pentru autentificarea Linux și să încetăm să mai folosim NIS (nici un argument real acolo;) și așa că lucrăm la utilizarea SSSD pentru a face acest lucru (care pare a fi popular [doar?] modalitate de integrare a autenticării Linux împotriva AD.) Problema cu care ne confruntăm este cum să asociem vechile valori UID și GID bazate pe NIS pentru utilizatori cu noua lor identitate bazată pe AD. De exemplu, utilizatorul meu AD-auth'd pe un sistem de testare are acest lucru de la getent passwd -s sss wdennis:

root@vm01:~# getent passwd -s sss wdennis
wdennis:*:140001116:140000513:Will Dennis:/home/wdennis:/bin/bash

Deci, evident, UID/GID este generat automat și nu corespunde cu valorile noastre actuale NIS. Făcând unele cercetări despre AD și schema acesteia, văd că atributele utilizatorului includ următoarele:

  • uidNumber
  • gidNumber
  • unixHomeDirectory
  • loginShell

Întrebarea mea, poate SSSD (sau orice folosim pentru autentificare) să consume cumva valorile uidNumber și gidNumber pentru a mapa UID-ul/GID-ul existent al fișierelor la noul utilizator autorizat AD? Sau, cum altfel putem asocia informațiile existente despre proprietatea fișierului cu utilizatorii autorizați AD? (Din cauza numărului de fișiere și mașini care le au, nu este cu adevărat posibil să chown fișierele către noile vale UID/GID...)

Puncte:1
drapel cz

Da, sssd poate folosi atributele POSIX de la AD în loc să-și facă propria mapare ID.

În secțiunea pentru domeniul dvs. AD în /etc/sssd/sssd.conf, pur și simplu setați ldap_id_mapping = false.

Dacă ați folosit deja maparea automată a ID-ului sssd pe un computer, asigurați-vă că ați golit memoria cache înainte de a reporni sssd.

rm -f /var/lib/sss/db/*

Atunci când se utilizează alăturarea tărâmului pentru a conecta un computer nou la domeniu, includeți opțiunea de linie de comandă --automatic-id-mapping=nu.

drapel cn
Functioneaza, multumesc! O altă întrebare -- aveți nevoie ca atributele POSIX să fie completate pentru fiecare utilizator care dorește să se autentifice prin SSSD? Sau există o modalitate de a permite unor oameni să aibă acele atribute și SSSD să le folosească și, dacă nu, generează valori?
Michael Hampton avatar
drapel cz
@WillDennis AFAIK este una sau alta pentru întregul domeniu, dar nu am mai atins una dintre aceste setări de câțiva ani.
Michael Hampton avatar
drapel cz
Și ca alternativă la toate acestea, luați în considerare plasarea sistemelor dvs. Linux într-un domeniu FreeIPA și configurarea unui trust pentru AD. Aceasta nu este o soluție la problema dvs. UID, dar este o soluție la problemele pe care le puteți avea în viitor, cum ar fi setarea politicilor sudo la nivelul întregului domeniu și alte funcții centrate pe Linux pe care FreeIPA le oferă și AD nu.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.