Innhold
Kvar AD-synk er knytta opp mot eit spread, og ei bestilling må då også gjerast for kvar AD-spread som skal brukast, til dømes ein for brukarar og ein for grupper. Kvart spread treng sin eigen spesifikasjon. Dette for å unngå forvirringar.
Sjå bestillingsmalen for eit dokument som kan brukast som utgangspunkt, for å fylle inn detaljane for ei bestilling. Bestillinga gjerast i samarbeid med Cerebrum drift, og bestillinga vert lagra på Cerebrum sine nettsider for vidare referansar. Dokumentet skal oppdaterast fortløpande etterkvart som det vert gjort endringar i synkroniseringa.
1 Bestillingsavklaringar
Alle spørsmål må besvarast og dokumenterast ved bestilling av ein ny AD-synk mot eit gitt spread, og må oppdaterast dersom det seinare trengs endringar. Dette så både instansen og Cerebrum er enige om oppsett.
1.1 Oppsett
Innstillingar for AD-synken. Desse punkta gjeld for alle synkroniseringar:
| Innstilling | Forklaring |
|---|---|
| Spread | Kva spread denne synken skal bruke. Alle entitetar med gitt spread vert forsøkt overførd til AD. Dømer:
|
| Domene | Namnet på AD-domenet AD-synken skal gå til. Dømer:
|
| WinRM server | Kva maskin er det Cerebrum skal kunne koble seg opp mot. Denne må vere satt opp med WinRM-tilgang med lokal brukar for Cerebrum, og må vere med i AD-domenet. Brannmurar må vere opne. Døme:
|
| Domenekontroller | Sett kva DC server synken skal kommunisere med rundt handtering av AD-funksjonalitet. Denne bør vanlegvis ikkje spesifiserast, og heller la AD sjølv få bestemme kva DC synken skal snakke med. AD lastbalanserer ved å gi oss forskjellig DC per synk. Det er berre i spesielle tilfeller det er behov for å spesifisere ein DC, til dømes når WinRM-serveren befinner seg i eit anna domene enn domenet synken skal oppdatere. Døme:
|
| Søke-OU | I kva OU i AD skal Cerebrum samanlikne data med. Denne OU-en vil bli vedlikeholdt til dømes ved at ukjende objekt av samme typen vil bli fjerna. Ein kan til dømes ha ein OU=Cerebrum å søke i, og legge vanlege brukarar i OU=Users,OU=Cerebrum, medan avvikla brukarar flyttast til OU=Deleted,OU=Cerebrum. Dømer:
|
| OU | I kva OU i AD skal entitetar leggast i. Objekt som finnast utanfor vil kunne bli flytta til gitt OU dersom dei har samme namn som entitetar i Cerebrum. Dømer:
|
| OU å ignorere | Dersom det er visse OU som ikkje skal rørast av Cerebrum, må for det første Cerebrum ikkje ha tilgang til å administrere OU-et. For det andre kan det leggast i denne lista, så vil Cerebrum heller ikkje prøve å finne på å oppdatere objekt som skulle ligge der. Dette er typisk dersom det finnast ein entitet i Cerebrum med samme namn som eit objekt i AD, og synken vurderer å flytte objektet til sitt OU. Dømer:
Standardverdi:
|
| Oppkoblingsbrukar | Brukarnamnet til den lokale brukaren på WinRM server. Passordet må bli gitt til Cerebrum drift på andre måtar. Standardverdi:
|
| Domenebrukar | Brukarnamnet til AD-brukaren som skal brukast av Cerebrum for å administrere delar av AD-domenet. Brukaren må vere satt opp med riktige tilgangar, og må vere mulig å bruke frå WinRM server. Standardverdi:
|
| Namneformat | Dersom namnet skal vere annleis i AD enn det er i Cerebrum. Dette gjeld typisk grupper, då dei i AD ikkje kan ha same namn som brukarar. Synken kan då legge til ein prefiks eller suffiks på namnet i AD. Dømer:
Standardverdi:
|
| Flytte objekt | Dersom synken finn eit objekt som ligg i feil OU, skal objektet då flyttast til riktig OU? Det typiske dømet er objekt som ligg utanfor Cerebrum sitt OU, og som då skal flyttast inn. Standardverdi:
|
| Opprette OU | Dersom OU-et synken skal oppdatere ikkje eksistere, skal det då berre feilmeldast, eller skal synken opprette OU-et? Standardverdi:
|
| Kva skal skje med ukjende objekt | Kva skal synken gjere med objekt i AD som den ikkje finn att i Cerebrum. Mulige alternativ:
Standardverdi:
|
| Kva skal skje med deaktiverte objekt | Kva skal synken gjere med objekt i AD som er i karantene i Cerebrum. Alle typar entitetar kan vere i karantene i Cerebrum, dette gjeld ikkje berre brukarar. Mulige alternativ:
Standardverdi:
|
| Lagring av SID | Skal synken lagre SID til objekta i Cerebrum? Dette brukast per i dag ikkje til noko anna enn for visning. Standardverdi:
|
| Gruppetype | Gjeld berre for grupper: Kva gruppetype gruppa skal bli oppretta med. Dette vil ikkje sjekkast ved seinare oppdateringar. Standardverdi:
|
| Spread for gruppemedlem | Gjeld berre for grupper: Kva medlem av gruppene skal bli tatt med til AD, basert på spread. Medlemma må eksistere i AD, så slike spread må allereie ha ein AD-synk. Døme:
|
| Hyppighet på full synk | Kor ofte skal full synk køyre? Ein gang i døgnet? Ein gang i timen? Full synk vil ta minst to minuttar dersom ingen avvik vart funne, og den henter ut ein god del informasjon frå AD, så den vil kunne bruke noko ressursar frå ein DC og oppkoblingsserveren. Standardverdi:
|
| Hyppighet på hurtigsynk | Kor ofte skal hurtigsynkten køyre? Ein gang kvart 10. minutt? Denne tek som oftast ein god del kortare tid, og vil ikkje kontakte AD dersom ingen endringar vart funne. Standardverdi:
|
1.2 Attributtar
Vi treng ei full liste over kva attributtar som skal oppdaterast i AD for entitetane med gitt spread. Lista må delast opp i dei ulike kategoriane av attributtar, etter korleis dei vert brukt/generert av AD-synken:
Standard-attributtar generert av den generelle AD-synken, basert på anna informasjon i Cerebrum. Til dømes kan Surname bli generert ut frå namnet på personen i Cerebrum. Sidan instansar kan ha ulikt behov for kva dei treng i eit attributt treng vi å definere kva informasjon i Cerebrum attributtet skal fyllast med.
For slike attributt treng vi:
- Namn på attributtet.
- Kva type informasjon som skal brukast, med innstillingar. Informasjonstypen må vere definert i TODO.
Attributtar som kjem frå AD-attributt-tabellen i Cerebrum. Synken kan enkelt ta i bruk attributtar som kjem frå denne tabellen, men dei må administrerast på andre måtar. Nokre attributtar vil kunne administrerast manuelt av instansen gjennom bofh, medan andre kan bli automatisk oppdatert gjennom anna funksjonalitet i Cerebrum. Ein slik automatikk må i så fall settast opp, eventuelt må det utviklast funksjonalitet.
For slike attributt treng vi:
- Namn på attributtet.
- Ein beskrivelse av korleis attributtet skal genererast. Skal det til dømes berre kunne settast manuelt gjennom bofh, eller skal det også bli automatisk generert ut frå hendingar i Cerebrum?
- Standardverdi for attributtet dersom det ikkje eksisterer for ein entitet.
- Kven skal kunne administrere attributtet gjennom bofh? Superbrukarar vil ha tilgang til dei fleste attributtar.
Attributtar som synken automatisk genererer, men som er spesialtilpassa instansen og kan då ikkje vere ein del av den generelle synken. Vi ønsker slike lokale tilpassingar i minst mogeleg grad. Dette er likevel avhenger av behov og formål, så det kan vurderast ved bestilling.
For slike attributt treng vi:
- Namn på attributtet.
- Ei beskriving av korleis attributtet skal genererast. Vi samarbeider om å utarbeide ei så konkret beskriving som mulig, for å unngå misforståingar.
1.3 Skript
Dersom det er behov for å køyre skript på AD-sida ved visse hendingar, til dømes ved oppretting av nye brukarar, eller for andre tenester, som Exchange, Lync, Office365. Se Scripts i AD2-synk for meir informasjon om oppsettet.
Cerebrum treng ein oversikt over full path til powershell-filer som skal køyrast, og for kva type hendingar.
1.4 Lokale tilpassingar
Dersom den generelle AD-synken ikkje dekker all funksjonalitet det er behov for, må vi gjere lokale utvidingar/tilpassingar. Vi treng i så fall ein beskrivelse av kvar funksjonalitet som trengs. Merk at vi ønsker å ha minst mogeleg av slike tilpassingar, då det krever meir vedlikehold av kode, spesielt vil seinare endringar av felleskode ta lenger tid.
1.5 Migrering/forberedingar
Dersom det trengs å gjerast migreringar før oppstart av ny AD-synk. Dømer:
- Ein eingangsjobb der vi set nytt spread på alle entitetar i Cerebrum som oppfyller visse krav. For brukarar kan det til dømes vere at personen har ei aktiv tilknytting frå eit autoritativt kjeldesystem, eller at brukaren har eit eksisterande spread for ein gamal AD-synk.
- Dersom nye attributt skal leggast i AD-attributt-tabellen, vil vi måtte kunne køyre ein eingangsjobb som populerer dette attributtet for alle relevante entitetar. Vi treng då informasjon om kva entitetar som skal få det satt, og kva feltet skal innehalde.
- Ved migrering til nytt AD-miljø kan det vere behov for å migrere heimeområder og andre data. Dette bør vanlegvis gjerast på AD-sida, men Cerebrum kan bistå der vi kan.