Innføring av posix-grupper i AD på UiO

Bakgrunn for lagringsløysinga

Når HNAS (Hitachi NAS - fillagringsbiten av Hitachi-lagringen) brukes til delte tilganger via CIFS/SMB, slår den opp gruppenavnet i AD for å finne gruppemedlemmer, for å sjekke om aktuell bruker er med i gruppa og dermed skal ha tilgang som gruppemedlem. Det er slik tilgangsstyring i CIFS/SMB er implementert på HNAS, ifølge Hitachi.

Siden grupper har forskjellig navn på unix/NFS-siden (<gruppenavn>) og AD (<gruppenavn>-gruppe), får ikke HNAS slått opp gruppa i AD, og brukeren får ikke tilgang i henhold til gruppemedlemsskapet. Før vi får mulighet for å styre tilgang gjennom gruppemedlemsskap via CIFS/SMB, får vi ikke brukt HNAS til delte tilganger (les: fellesområder) for Windows- og MacOSX-klienter.

Forskjellene i gruppenavn i de to verdenene er ikke noe problem for hjemmeområder, siden delte tilganger ikke skal brukes her.

Det å få testa delte tilganger og fellesområder fra HNAS er noe som vi må få gjort snarest, for å fange opp eventuelle problemer som må følges opp. Førsteprioriteten vår nå er å få flytta over flere USIT-hjemmeområder for å få erfaring med disse i litt større skala, og rett etter dette kommer å få testa/brukt fellesområder.

Cerebrum

Løysinga er å ha samme gruppenamn i AD og Cerebrum. Utfordringa med dette er at brukarnamn og gruppenamn i AD bruker det samme namnerommet, sjå lista over konfliktar. Vi kan til dømes ikkje opprette både brukaren jokim og gruppa jokim i AD. Dette er årsaken til at vi gjekk for å legge til -gruppe på slutten av alle gruppenamn i AD. Unix-verdenen har ikkje denne begrensinga, og er årsaken til kvifor vi har dette opplegget på UiO.

Vi kan heller ikkje berre endre gruppenamn, då det mest sannsynleg er mange tenester som baserer seg på gruppenamn og som ved endring ikkje vil fungerer som det skal lenger. Det er heller ikkje nokon oversikt over kva tenester dette er, så vi har heller ingen mulighet til å sjå konsekvensane av ei slik endring. Merk at dette gjeld både for unix- og AD-miljøet, begge sider baserer seg på gruppenamn.

Når det gjeld namnekollisjonar har vi to forskjellige typar:

1. Personlege filgrupper. Desse gjenkjennast i dag ved at dei har samme gruppenamn som brukaren som eig dei sitt brukarnamn. Personlege filgrupper brukast berre av brukarar som eigast av personar.
2. Systemgrupper som kolliderer med systembrukarar. Upersonlege brukarar kan ha samme brukarnamn som eit eksisterande gruppenamn, uavhengig av om det er noko samanheng mellom brukaren og gruppa. Desse tilfella kjem av historiske årsaker, då det for eit halvt år sidan vart innført ei sperre mot å få oppretta brukarar eller grupper dersom det kolliderte med eksisterande entitetar. Slike tilfeller er då noko som med fordel kan ryddast opp i.

Alternativ 1: Endre lagringssystemet til å takle suffix i gruppenamn

Det er to løysingar for dette:

• 1.1 Endre lagringssystemet til å takle forskjellige gruppenavn-standarder for unix/NFS og CIFS/SMB/AD

  I teorien kan vi be Hitachi om en slik endring, som da vil bli underlagt en sentral priorieringsprosess hos Hitachi. Dersom forespørselen kommer høyt nok opp i prioriteringen, blir den implementert. Det er usikkert om vårt behov ville nådd opp i prioriteringen, og om den hadde gjort det, ville det tatt tid å få endringen implementert, og tid har vi ikke. Så i praksis er dette ikke en reell mulighet.

  Oppfattinga er at andre kundar av systemet registrerer ting i AD og har difor ikkje vår utfordring med konfliktar mellom grupper og brukarar.

• 1.2 Vedlikeholde mapping mellom unix- og AD-grupper på lagringssystemet

  Det er mulig å kjøre kommandoer på HNAS som spesifiserer mapping mellom unix-gruppenavn, unix-GID og AD-gruppenavn, dette gjøres for en og en gruppe. Vi har gjort manuelle tester av dette for noen få grupper, og ser at det virker.

  I teorien kunne vi scriptet et opplegg som kjører gruppemappingskommandoer på HNAS, med Cerebrum-info om unix- og AD-gruppenavn og tilhørende GID-er som input. Vi har ikke sett nærmere på denne muligheten, siden vi så at HNAS' CIFS/SMB-gruppeoppslag virker om gruppenavnene (uten suffiks) legges inn i POSIX-delen av AD.

  Vi hadde besøk av en Hitachi-ekspert to dager i forrige uke som frarådet en slik løsning, siden HNAS ville måtte gjøre gruppeoppslag i mapping-tabellen.

  I dag er det litt over 45.000 filgrupper i NIS. Vi har ingen praktisk måte å identifisere hvilke filgrupper som vil bli brukt på HNAS, så et scriptopplegg for vedlikehold av gruppemappinger må i utgangspunktet inkludere alle grupper. Rundt 90% av UiO-filgruppene har ikke medlemmer, så de kunne utelukkes av scriptet. Det vil uansett dreie seg om endel tusen gruppemappinger. Vi vet ikke hvor effektivt HNAS slår opp i gruppemappinger, eller hvor mye prosesseringskraft det er tilgjengelig til dette. Jeg vil anta at et slikt opplegg, når de nye filtjenerne er i full produksjon, vil gi en målbar ytelsesreduksjon for brukerne.

  Hvis det viser seg at det tar lang tid å få gjennomført alternativet vi går for, må vi se på hva som kan gjøres for å få tatt i bruk fellesområder i større skala. En mulighet kan være å scripte gruppenavnmapping på lagringssystemet, som jeg skisserte i går. Vi vil helst ikke gjøre dette, men om vi må, vil det kun være som en midlertidig løsning. Det vil være noe jobb med dette: generering av gruppe-dump fra Cerebrum, sette opp oppdateringsrutiner på HNAS, håndtering av mulige navnekollisjoner.

Alternativ 2: Rydde opp i kollisjonar i grupper og brukarar og endre AD-synken

Ei mulig løysing er å først rydde opp i namnerommet og fjerne alle namnekollisjonar, som gjer at vi kan endre AD-synken til å ikkje lenger ha suffiks på gruppenamn. I tillegg må vi endre namneformatet til personlege filgrupper i Cerebrum, til dømes ved å legge til eit suffiks -personal.

Dette er den ryddigaste løysinga etter mi meining, då det tvinger oss til å rydde opp i noko som allereie burde blitt rydda opp i. Løysinga krever at det varslast, testast grundig, og det vil kreve ein del oppfølging frå alle relevante systemeigarar på UiO.

Konsekvensen av denne løysinga:

• Nokon må ha det overordna ansvaret for oppfølging av at endringane kjem på plass, og at alle system takler endringa.
• Alle grupper i AD vil få fjerna suffiks -gruppe.
• Alle personlege grupper vil få eit suffiks, td. -personal. Dette vil påvirke alle system gruppene vert eksporterte til.

Kva arbeid dette vil kreve:

• Cerebrum må produsere lister over kollisjonar og endringar, lage skript for å endre namna på alle personlege filgrupper og endre namneformatet til alle nye, personlege filgrupper. Dette er estimert til å ta 3 dagar totalt. Samarbeid og oppfølging vil komme i tillegg.
• Unix-drift må rydde opp i alle namnekollisjonar. Det er 389 namnekonfliktar per 14. mai 2013, men rundt halvparten av desse ser ut til å vere for gamle ifi-emner.
• Systemeigarar må bli informerte og involverast i endringa av namnerommet.
• AD-administratorar må skripte alle namneendringane i AD, og følge opp når AD-synken vert endra, så gruppene beheld samme SID.

Alternativ 3: Legge til suffiks på alle grupper i Cerebrum

Eit anna alternativ er at vi i Cerebrum endrar alle grupper ved å legge til suffiks -gruppe på dei. Det vil då vere samsvar mellom unix- og AD-verdenen, så lagringsløysinga vil fungere.

Fordelen med dette alternativet er at AD-miljøet og tenester som bruker AD ikkje treng å endrast. Vi treng ikkje å måtte rydde opp i kollisjonar, og vi treng heller ikkje å gjere noko spesielt med personlege filgrupper.

Den store ulempa med denne endringa, er at unix-verdenen vil måtte endre på seg noko voldsomt, då den påvirker absolutt alle grupper, også dei utan AD-spread. Det er også ei lite elegant løysing, så vi fraråder dette alternativet sterkt. Det vil også i praksis ikkje vere mulig å gjere dette for absolutt alle grupper, til dømes har Fronter eigne krav til gruppenamn, så det vil framleis vere visse grupper som er utan gitt suffiks. Dette kan fort bli forvirrande.

Konsekvensen av denne løysinga:

• Dei fleste grupper i Cerebrum vil få ein suffiks, td. -gruppe, også sjølv om dei ikkje har AD-spread.

Kva arbeid dette vil kreve:

• Cerebrum må produsere lister over endringar, lage skript for å endre namna på alle grupper, og legge inn sjekkar i td. bofh for at ein berre kan opprette nye grupper dersom dei slutter på gitt suffiks. Det må også sjekkast at det meste av funksjonalitet som oppretter grupper tek hensyn til eit slikt suffiks, som vil ha ein del konsekvensar. Nokre system Cerebrum eksporterer til vil også måtte tilpassast. Dette er estimert til å ta 5 dagar totalt. Samarbeid og oppfølging vil komme i tillegg.
• Systemeigarar må bli informerte og involverast i endringa av namnerommet.
• AD-administratorar må skripte alle namneendringane i AD, og følge opp når AD-synken vert endra, så dei beheld samme SID.

Alternativ 4: Sjå på endring av AD-attributtar

AD har ulike attributtar som brukast som identifikatorar for brukarar og grupper:

• SAMAccountName: Er fallback for brukar- og gruppenamn. Må vere unikt i heile domenet.
• Name: Er ein del av DistinguishedName (dn), som brukast som identifikator for alle objekt. Name må berre vere unikt i OU-et objektet ligg i.

Dersom lagringssystemet ser på DN eller Name kunne vi satt riktig gruppenamn i Name og beholdt gruppenamn med suffix i SAMAccountName. Dette er ikkje blitt sett på.

Ei slik endring vil kreve:

• Utvikling av endring i Cerebrum sin AD-synk: 5 dagar.
• Testing og verifisering på AD-sida.
• Testing og verifisering av alle andre system som bruker grupper i AD.

Denne løysinga kan stå i fare for å forvirre både brukarar og skript, då vi til no har gått ut frå at desse attributta er like. Sidan vi ikkje ser på dette som ei bra løysing, har vi heller ikkje sett på kva konsekvensar og arbeid dette vil påføre.

Alternativ 5: Lage eit nytt spread for fildelingsgrupper

Ei anna løysing kan vere å lage eit nytt spread i Cerebrum for grupper som skal brukast av lagringsløysinga, til dømes SMB_group. Alle slike grupper vil då bli oppretta i AD i ein eigen OU, og utan noko suffiks. Du vil ikkje kunne sette SMB-spread på grupper som er i namnekonflikt, så personlege filgrupper kan ikkje brukast for dette dersom vi beheld namnegivinga som i dag.

Det er minst to krav til at dette alternativet skal vere brukbart:

• Lagringssystemet må kunne takle oppslag i to ulike OU i AD for å hente ut gruppemedlemskap. Cerebrum kan ikkje legge desse gruppene inn i samme OU som vanlege grupper i AD, det vert for grisete og noko synken ikkje takler utan ein del vidareutvikling.
• Det må vurderast om dette er brukbart for oppsettet i AD. AD kobler rettigheter mot gruppa sin SID, og Cerebrum ikkje kan sette denne, det dikterast av AD og den er unik for kvart AD-objekt. Dette gjer at rettigheter mellom den vanlege AD-gruppa og SMB-gruppa ikkje vil samsvare, og eventuelle rettigheter må leggast inn to ganger. Dette er berre ei synsing, og må vurderast av nokon med bedre AD-kompetanse.

Konsekvenser:

• Personlege filgrupper vil ikkje lenger kunne brukast til fildeling, med mindre vi endrer namnebruken på desse, som nemnd i Alternativ 2.
• Vi endrar ikkje eksisterande struktur, så dette alternativet vil ikkje få konsekvenser utover lagringssystemet.
• At det dukker opp to ulike grupper i AD for samme gruppa i unix-verdenen vil kunne skape forvirring for administratorar.

Ei slik endring krever:

• BSD må finne ut om lagringssystemet kan tilpassast å bruke fleire OU frå AD. Å legge SMB-grupper i samme OU som vanlege grupper og brukarar vert fort veldig grisete.
• Cerebrum må lage nytt spread, og sette det opp for bruk i bofh. Ein ny AD-synk må settast opp for denne typen spread.
• AD-administratorar må tilpasse AD for mottak av SMB-grupper.
• Alle administratorar må bli informerte om at å ta i bruk nye fellesområder krever eit eige spread, og kan ikkje brukast for grupper som er i konflikt med brukarnamn, som personlege filgrupper.

Alternativ 6: Eit eige LDAP-tre

Vi kan opprette eit nytt LDAP-tre berre til bruk for lagringssystemet, der alle grupper får suffiks -gruppe, men beheld samme GID. Dei vil då ha samme namn som i AD, og beheld samme rettigheter som frå posix-treet. Gruppa vil eksistere to ganger, med samme GID og medlemskap, men med ulikt gruppenamn. Dette kan vere forvirrande, men dersom det berre brukast for lagringssystemet kan det vere overkommeleg.

Det ser ut til at det nye lagringssystemet ikkje støtter LDAP så bra, berre AD sin variant av LDAP. Det er difor uvisst om dette kan brukast av lagringssystemet, og kva konsekvenser det får for rettigheter og skript.

Konsekvenser:

• Det vil kunne skape forvirring at grupper med samme GID eksisterer fleire stader.
• Sidan det nye posix-treet berre skal brukast av lagringssystemet, og vi gjer ingen endringar i eksisterande struktur, vil dette ikkje skape konsekvensar utover lagringssystemet.

Arbeid som krevast:

• Unix-drift må verifisere at det er mulig å bruke grupper med ulikt namn, men samme GID.
• Lagringsgruppa må verifisere at løysinga kan brukast av lagringssystemet.
• Katalog-drift må sette opp eit nytt posix-tre.
• Cerebrum må eventuelt sette opp ein ny synk til LDAP. Dette avhenger av kor mykje katalog-drift gjer på si side.

Alternativ 7: Legge gruppene inn dobbelt i NIS

Cerebrum kan legge alle grupper med eit gitt SMB-spread dobbelt opp i NIS, ein gang med vanleg gruppe, og ein gang med suffix -gruppe, men begge med samme GID. På den måten beheld ein samme rettigheter, via GID, og får samme gruppenamn som i AD.

Før dette kan bli gjennomfør må vi finne ut om NIS støtter to grupper med samme GID, og om det kan skape andre konsekvensar for NIS.

Dette er det enklaste alternativet, som ser ut til å vere mulig å gjennomføre.

Konsekvensar:

• Synken til NIS vert meir kompleks for Cerebrum.
• Vi får ein ny spread å måtte forholde oss til. Alternativt kan vi berre legge inn absolutt alle posixgrupper dobbelt opp i NIS, men det må i så fall vurderast om NIS takler dobbelt så mange grupper som i dag utan at det går på bekostning av ytelsen.
• Ingen andre enn lagringssystemet treng å forholde seg til dei nye gruppene. Det kan riktignok vere forvirrande.

Arbeid som krevast:

• Cerebrum må lage ein ny spread, SMB_group, og lage ein ny NIS-synk. Grupper med dette spread'et inkluderes på linje med grupper med AD_group ved synk til AD og inkluderes med "-gruppe"-postfikset navn i eksport til NIS.
• Unix-drift må teste og verifisere at doble grupper fungerer utan at NIS knekk.
• Lagringsløysinga må teste og verifisere at løysinga fungerer.

Opprydding

Før vi kan endre AD-synken må vi få fjerna alle namnekollisjonar. Driftseksjonen får ei liste frå Cerebrum med alle grupper som kolliderer med upersonlege brukarar. Alle tilfella må ryddast opp i, ved å:

1. Slette gruppa. Systema som bruker gruppa må varslast og tilpassast.
2. Endre namn på gruppa. Cerebrum drift kan hjelpe til med dette. Dette vil berre virke for unix, sidan vi då beheld GID. For AD må det gjerast andre grep.
3. Avvikle brukaren. Systema som har behov for brukaren må varslast og tilpassast.

Vi vil ikkje kunne fortsette prosessen før alle slike tilfeller er fjerna.

Utviklinga av ei slik liste vil ta opp i 4 timar.

Endring av personlege filgrupper

Vi må endre funksjonaliteten som oppretter personlege filgrupper til å legge til eit suffiks i gruppenamnet, til dømes -personal.

Kva som må gjerast:

• Alle eksisterande personlege filgrupper må få endra namnet sitt. Dette er ein eingangsjobb, men lista over endringar må først verifiserast, og kan ikkje settast i produksjon før dei samme endringane er blitt gjort på AD-sida.

  Sjølve utviklinga vil ta 5 timar. Vidare oppfølging vil ta lenger tid.

• Ved oppretting av nye, personlege filgrupper må ein ta hensyn til nytt namneformat. Dette må gjerast både for bofh-kommandoar og for andre tenester, som den automatiske opprettinga av studentbrukarar.

  Utviklinga vil ta 9 timar, inkludert oppfølging.

Endring av AD-synken

AD-synken må endrast til å ikkje lenger legge til suffiks på grupper.

Kva som må gjerast:

• Endringa i AD-synken er berre ei konfig-endring, men det må testast at synken fungerer riktig med ein tom suffiks.

• Alle andre system må vere klar over endringa før vi kan utføre det. Det er usikkert kor mykje arbeid dette er.

• Det er viktig å beholde eksisterande tilgangar i AD, som registrerast per SID, så gruppenamna må på førehand endrast rett før vi endrer AD-synken, hvis ikkje vil den i staden for berre opprette nye grupper og slette dei gamle.

  Dette krever at AD-administratorar og Cerebrum samarbeider om overgangen:

  1. Cerebrum lager ei liste over alle gruppenamnsendringane for dei gruppene som har AD-spread. Dette gjeld både grupper som får fjerna -gruppe, men også endringane for personlege filgrupper. Det er snakk om rundt 16-17000 grupper. Lista sendast over til AD-administratorar.
  2. Cerebrum stopper all synk mot AD. Gruppenamnsendringar for personlege filgrupper utførast i Cerebrum.
  3. Samtidig skripter AD-administratorar lista over endringar og bytter namn på alle gitte grupper i AD.
  4. Cerebrum set i gang ei testkøyring mot AD, for å sjekke om endringane har blitt riktige.
  5. Når Cerebrum starter synken att, skal det vere samsvar mellom Cerebrum og AD, men då med likt gruppenamn.

• Endringa vil måtte følgast opp i etterkant. Det vil mest sannsynleg dukke opp problem etter endringa, som vi må ta høgde for å ha kapasitet til.