Behov i ny AD2-synk for instansar

Ein samla oversikt over manglar og behov i Cerebrum sin integrasjon med AD, her kalla AD2-synk. Dette dokumentet er meint å brukast som forbereding til ein eigen sprint som er dedikert for AD-integrasjonen, i midten av år 2015.

1   Status på dokumentet

Status: I dialog med partnarane for å samle inn behov.

Dato Kva er blitt gjort
2015-02-11 Førsteutkast
2015-02-20 Utvida med tilbakemeldingar frå HiØ
2015-02-26 Utvida med tilbakemeldingar frå NIH
2015-03-03 Fastsatt tidsfristar
2015-05-25 Utvida med fleire tilbakemeldingar frå NIH

2   Introduksjon

USIT har eit mål å få alle Cerebrum-instansar over på ny AD-integrasjon til sommaren, for å redusere teknisk gjeld ved å fjerne den gamle.

Prosessen for å komme dit:

  1. Partnarane starter så fort som mulig med:

    • Sette opp Windows-sida av integrasjonen. Dette kan gjerast før alle detaljar rundt integrasjonen er avklart.

      Dette må vere klart seinast 1. juni, men jo før jo bedre.

    • Vurdere eige testmiljø for å kunne køyre akseptansetest av ny AD-integrasjon.

  2. USIT har dialog med alle partnarane og samler felles behov, sjå lenger ned.

    Frist: 13. mars.

  3. Alle partnarar må ha meldt inn sine behov, og ha sendt inn bestilling for oppsett av ny AD-integrasjon.

    Formell bestilling må sendast av partnaren per e-post til cerebrum-kontakt@usit.uio.no.

    Frist: 1. april.

  4. Bestillingane vert tatt med i sprinten dedikert for AD2-synk. Denne pågår i perioden 1. juni - 19. juni 2015.

  5. Målet er å få alle som ønsker det over på ny AD-integrasjon innan 1. juli 2015. Dette avhenger av at oppsettet er klart på Windows-sida, og at partnarar har fått testa og akseptert løysinga.

PS: Behov vert formulert som user stories, då vi utviklar med Scrum som metodikk.

2.1   Instansar

  • UiA - i produksjon, ønsker meir funksjonalitet
  • HiØ - i produksjon, ønsker meir funksjonalitet
  • HiNesna - i produksjon
  • NMH - spesifisert, venter på utvikling
  • NIH - spesifiserer
  • HiH - spesifiserer
  • ØFK - i dialog
  • TSD - i produksjon, ønsker meir funksjonalitet
  • UiO - ikkje prioritert

3   Bestillingar

3.1   Ulike OU

Som AD-administrator treng eg at Cerebrum-entitetar vil kunne opprettast og oppdaterast i ulike OU basert på kriterier, som brukartilknyttingar.

Dette er bestild av NMH, då dei har eit behov for å kunne legge tilsette og studentar i ulike OU.

Også bestild av NIH.

Backlog id 288.

3.2   Kjapp oppdatering av karantener

Status: Implementert

Som brukar-objekt treng eg å bli enabled/disabled like kjapt som nye passord vert oppdatert.

Dette er bestild av UiO i samanheng med digital eksamen, for å redusere ventetida for eksamenskandidatar som har blitt satt i karantene og må låsast opp. Behovet er også blitt nemnd av UiA.

Backlog id 222.

3.3   Gjenoppretting av brukarar

Som brukar vil eg kunne bli gjenoppretta dersom mitt tidlegare, sletta AD-objekt ligg i Recycle Bin. Dette gjer at eg kan beholde min SID og UUID og med det beholde rettigheter og innstillingar i AD. Dette må kunne konfigurerast, då det er ikkje ønskeleg hos alle instansar.

Bestilt av UiA i samanheng med innføringa av Recycle Bin i oppgraderinga av domenenivået.

Backlog id 115.

3.4   Skript ved endringar

Som AD-admin har eg behov for at Cerebrum automatisk kaller på definerte powershell-skript ved endringar. Cerebrum har ansvar for å kalle på skriptet, AD-admin har ansvar for å legge inn det som trengs av funksjonalitet i skriptet.

3.4.1   Feilhandtering

Det er i utgangspunktet ikkje noko kontroll på tilbakemeldinga frå slike skript. Instansen må sjølv legge til funksjonalitet i skriptet for å varsle internt dersom noko skulle feile. Dersom det er eit behov for at Cerebrum har noko ekstra handtering ved feil må du gje beskjed om at dette er eit behov. Hvis ikkje implementerast det utan feilhandtering.

Dersom de ønsker at Cerebrum skal logge eksekvering og evt. feilmelding nokon stad, må du melde inn dette som eit behov.

3.4.2   Endringstypar

Endringstypane det har blitt meldt om behov for:

  • Ved oppretting av eit nytt AD-objekt. Treng å få med SAMAccountName som parameter.
  • Ved avvikling av eit AD-objekt. Treng å få med SAMAccountName som parameter.
  • Ved oppdatering av eit eller fleire attributtar på eit AD-objekt. Treng å få med SAMAccountName, samt ei liste over kva attributt som har blitt oppdaterte. Attributta er allereie satt på objektet, så verdiane kan hentast derfrå.
  • Ved enabling av eit AD-objekt. Treng å få med SAMAccountName som parameter.
  • Ved disabling av eit AD-objekt. Treng å få med SAMAccountName som parameter.

Merk: Alle skriptkøyringar vil skje rett etter at endringa har blitt gjort i AD.

3.4.3   Skripteksekvering

HiØ har kome med eit forslag til korleis det er ønskeleg at skriptet skal fungere. Ein har då eitt felles skript for alle hendingstypar:

Kan vi gjøre noe slikt som dette:

c:\Scripts\eventHandler.ps1

med parametere (foreløpig):

userAdded | userDeleted | userQuarantined | userModified [-userPrincipalName n]

eks.:

c:\Scripts\eventHandler.ps1  userAdded -userPrincipalName username@hiof.no

som kalles fra cerebrum.

Skriptet bør akseptere at Cerebrum sender inn hendingstypar som de ikkje gjer noko med, utan å feile. Det vil då vere enklare å kunne utvide skriptet for å handtere nye hendingar, ved behov, utan å måtte vente på Cerebrum.

Folk må gjerne komme med innspel og preferansar til dette.

Backlog id 223, 392. TODO: ny user story

3.5   Brukar-tilknyttingar som kriterie

Som brukarkonto treng eg å få mine AD-attributtar satt ulikt basert på kva brukar-tilknyttingar eg er registrert med. Kriterie for dette defineres i konfigurasjonen.

Dette trengs til dømes for å kunne sette ulik verdi i HomeDirectory basert på om brukaren er student eller ansatt.

Behov meldt inn av NMH.

Backlog id 289.

3.6   Sette attributtar berre ved oppretting

Som AD-admin har eg behov for at gitte attributtar berre settast ved oppretting, slik at eg kan sjølv endre dei fritt etterpå. Dette gjer det enklare å til dømes flytte brukarar i tilfella der alt rundt dette berre gjerast i AD, og får meir kontroll enn å måtte involvere Cerebrum.

Behov vart meld inn av NIH. Behov eksisterar ikkje lenger, så dette er ikke lenger bestilld av NIH.

Backlog id 296.

3.7   Bruk av stillingsinformasjon for attributtar

Som AD-admin har eg behov for å kunne legge til stillingsinformasjon i attributtar.

Behov meldt inn av HiØ og UiA. HiØ har konkret behov for å fylle inn stillingstitlar i AD, som er registrert på stillingar, sjå Import frå DFØ-SAP.

Backlog id 393.

3.8   Manuelle enkelt-attributtar

Som AD-admin har eg behov for å kunne sette enkelt-attributtar manuelt i AD, sjølv om dei oppdaterast av Cerebrum, dersom entiteten oppfyller visse kriterier, til dømes at ein brukar ikkje har studenttilknytting. På denne måten vil Cerebrum automatisere attributtet, og samtidig la AD-admin kunne sette den manuelt for enkelte grupper ved å ignorere det for desse.

Ulempa med dette ønsket, er at det kompliserer dataflyten (ein kan ikkje vite kor verdien i attributtet kjem frå), og Cerebrum vil slette eksisterande verdiar i attributt straks entiteten skulle oppfylt kriteria. Eit alternativ er at slike attributtar lagrast ved å registrere dei gjennom bofh, sjå AD-kommandoar i bofh.

Bestilld av NIH.

Backlog id: 27.

3.9   Pause enkelt-entitetar

Som AD-admin har eg behov for å midlertidig kunne pause spesifikke entiteter frå å bli oppdatert av AD-integrasjonen. Dette for å kunne gjere større endringar på AD-objektet, til dømes flytte det, utan at Cerebrum skal komme i vegen.

Nemnd av UiA som eit mulig behov. Må i så fall bestillast. Bestilld av NIH.

Backlog id: 41.

3.10   Logging på AD-sida

Som AD-admin ønsker eg å få fortløpande loggar frå AD-integrasjonen.

Dette kan løysast på ulike måtar, til dømes at Cerebrum køyrer powershell-kommandoar for å logge på Windows-sida, enten til maskina eller i AD. Detaljar har ikkje blitt diskutert med partnarane, så vi har ikkje nok informasjon om behov for å kunne løyse dette, men vi ser i utgangspunktet for oss å bruke https://technet.microsoft.com/en-us/library/hh849847.aspx og logge til domenekontrolleren vi køyrer synk mot. Merk at AD gir oss ein tilfeldig DC ved starten av kvar fullsynk, så det vil då bli logga til ulike DC-ar per synk.

Ønskeleg av Cerebrum drift.

Backlog id: 394

4   Manglar

Kjende feil som må fiksast

  • CRB-662 - Feil i oppdatering av enkelte singlevalued attributtar. Gjer at enkelte objekt ikkje får oppdatert enkelte attributtar riktig i AD.
  • CRB-663 - Feil ved flytting av brukar som ligg utan search_scope. Gjer at brukarar ikkje kan flyttast mellom OU i visse situasjonar.
  • CRB-397 - Personmedlemskap feiler i gruppesynk. Gjer at grupper med personar som medlem ikkje vert oppdatert korrekt ved indirekte medlemskap. Vurderast som lite kritisk.

Cerebrum har forøvrig ein oppdatert oversikt over kjende feil i AD-integrasjonen.

4.1   Tabell over brukerhistorier

Backlog ID Partner PfM Pri Kommentar
288 ALLE Y 20  
115 ALLE N 25  
223 ALLE Y 1  
392 ALLE Y 10  
395 ALLE Y 15  
289 ALLE Y 30  
393 ALLE N 70  
27 ALLE ? ? PfM og Pri avklares i https://rt.uio.no/Ticket/Update.html?id=1778278
41 ALLE N 40  
394 ALLE N 100 Ville det værten bedre løsning å tilby logger via logstash (eller annet passende grensesnitt), samt pusse opp måten det logges på?
CRB-662 ALLE J 8  
CRB-663 ALLE J 28  
CRB-397 ALLE N 50  
397 ALLE J 0  
398 ALLE N 5  
Av jokim
Publisert 31. mai 2015 11:22 - Sist endret 13. jan. 2023 15:26
Del på e-post