Attributtar frå Cerebrum til AD

2.1   Felles-innstillingar

Felles konfigurasjon for alle standardelementa:

• Namn på attributtet: Attributtnamn kan velgast fritt frå Cerebrum si side, men attributtet må eksistere i AD sitt schema før Cerebrum kan populere det.

  Døme: SAMAccountName, DisplayName og UidNumber.

• Standardverdi (default): Om ein enkel verdi skal settast for eit attributt, til dømes ei standardstreng eller brukarnamnet til entiteten. Denne verdien vil også bli brukt for informasjonstypar der Cerebrum ikkje har den gitte informasjonen om entiteten. Til dømes kan vi legge inn ein brukar sitt kontortelefonnummer om vi har det, og evt. sette sentralbordet sitt telefonnummer som standardverdi.

  TODO: Ein kan også her sette DontUpdate for å ikkje overskrive eller endre attributtet i AD dersom vi ikkje har informasjon. Så unngår ein å overskrive eller blanke ut attributtet om Cerebrum ikkje inneheld noko bedre.

  Døme: Universitetet i Oslo, <Not Set>, (blankt felt) eller sentralbordet sitt telefonnummer.

• Transform (transform): Om verdien som finnast i Cerebrum skal endrast på før det settast i attributtet. Det er ikkje alltid informasjon vi har i Cerebrum kan brukast direkte.

  Døme: Gjere om til lowercase, fjerne "+47" frå starten av telefonnummer, eller kombinere element frå gateadresser.

• Kjeldesystem: Ei prioritert liste over kva kjeldesystem eventuell informasjon må komme frå for å kunne brukast. Denne konfigurasjonen avhenger av kva type informasjon som skal brukast, til dømes kontaktinformasjon. Denne innstillinga kan berre brukast av enkelte typar attributt - valg av kjeldesystem vil ikkje gje meining for til dømes traits, sidan dei ikkje kjem frå eit kjeldesystem. Dersom dette feltet er blankt hentast informasjonen frå alle kjeldesystem, og den første funne verdien brukast.

  Merk at konfigurasjonen for kjeldesystem og listene over informasjonen som skal hentast ut kan inneholde meir enn eitt valg kvar. I slike tilfeller vil AD-synken sjekke alle kjeldesystema for tilgjengeleg informasjon før den prøver neste informasjonstype. Til dømes vil ein i situasjonar der ein har SAP, FS og Manual som kjeldesystem og kontaktinformasjon skal vere kontortelefon og deretter telefonnummer, prøve å hente ut:

  1. Kontortelefon frå SAP?
  2. Kontortelefon frå FS?
  3. Kontortelefon frå Manual?
  4. Telefonnummer frå SAP?
  5. Telefonnummer frå FS?
  6. Telefonnummer frå Manual?

• Kriterier: Krav som må bli oppfylde for at innstillinga skal bli brukt for ein entitet. Dette styrer kven som skal kunne få informasjon i eit attributt og ikkje.

  Kriterier kan også brukast for å styre attributt som har fleire alternativ. Til dømes kan eit attributt bli fyld med noko informasjon for primærbrukarar, og noko heilt anna for dei som ikkje er primærbrukarar.

  Det er ulike typar krav:

  • Spread: Entiteten må ha minst ein av gitte spread for at eventuell informasjon frå Cerebrum skal bli brukt for attributtet.

    Døme: Krav om Exchange-spread for attributtar som er Exchange-spesifikke.

  • Primærbrukar: Krav til om entiteten må vere primærbrukar, eller om entiteten må ikkje vere primærbrukar.

    Døme: Berre primærbrukarar skal vere registrert med personen sitt telefonnummer, då det brukast av Lync eller instansen sitt VoIP-system.

  • Tilknytning: En spesifikasjon som definerer hvilke tilknytninger en bruker eller person må ha for å kunne få satt det aktuelle attributtet.

    Kriteriet kan ta hensyn til flere deler ved en tilknytning.

    Eksempelvis:

    • ANSATT, en hvilken som helst ansatt-tilknytning oppfyller kriteriet.
    • ANSATT@900000, ansatte ved stedkode 9000000 oppfyller kriteriet.
    • ANSATT/tekadm, kriteriet omfatter alle ansatte med tekadm-status.
    • 900000, kriteriet omfatter alle tilknyttet stedkoden.
    • ANSATT/tekadm@900000, ansatte av typen tekadm ved stedkode 900000.

    Det kan spesifiseres hvilket kildesystem tilknytning i kriteriet skal gjelde.

    Hvis det er ønskelig at kriteriet skal omfatte tilknytninger ved steder lavere i organisasjonsstrukturen, må det spesifiseres hvilket perspektiv som skal gjelde (hvilket kildesystem for OU-informasjon skal benyttes).

    Boolsk og/eller logikk med tanke på hvilke tilknytninger som utgjør kriteriet. Med andre ord, så kan man spesifisere at et kriterium krever STUDENT tilknytning på brukerkonto, og ANSATT på person.

2.2   Fleire mulige sjekkar

I nokre tilfeller er det behov for at eit AD-attributt fyllast med forskjellige data frå Cerebrum, avhengig av forskjellige kriterier, eller dersom Cerebrum mangler data for enkelte entietar.

Eit døme der det kan vere behov for at Cerebrum ser etter data fleire stader kan vere å sette Title. Nedanfor kjem ei liste over kva Cerebrum sjekker for å få satt tittel, og stopper på første punkt som gir eit treff:

1. Har Cerebrum fått ein tittel frå personalsystemet? I så fall settast denne.
2. Har Cerebrum ein manuelt registrert tittel for personen? I så fall settast denne.
3. Er brukarkontoen ein systembrukar? I så fall settast tittel til "Systembruker".
4. Har personen ei ansatt-tilknytting? I så fall settast tittel til "Tilsett".
5. Har personen ei student-tilknytting? I så fall settast tittel til "Student".
6. Til slutt settast tittel berre til "Ukjent".

Ein har sjeldan behov for ei så lang liste. Det kompliserer bildet, sidan ein ikkje veit umiddelbart kor informasjonen for slike AD-attributt kjem frå.

2.3   Kontaktinformasjon

Kontaktinformasjon som finnast i Cerebrum, til dømes telefonnummer, kontortelefon, mobilnummer. Ein har også e-postadresser lagra som kontakinformasjon for dei instansane som ikkje bruker e-postmodulen til Cerebrum. E-postadresser lagra som kontaktinformasjon kan berre vere ei adresse.

Ein har i tillegg til standardkonfigurasjonen valga:

• Kontakttypar: Ei prioritert liste over kva typar kontaktinformasjon som skal hentast ut. Kvar entitet får den første kontakttypen som er satt i Cerebrum.

  Døme: Telefonnummer, privat telefonnummer, mobilnummer, URL eller e-post.

2.4   Personnamneinformasjon

Personnamn som er registrert i Cerebrum, til dømes fornamn og etternamn til personar.

Ein har i tillegg til standardkonfigurasjonen valga:

• Namnevariantar: Ei prioritert liste over kva typar namn som skal hentast ut av Cerebrum.

  Døme: Fornamn, etternamn og fullt namn.

2.5   Namneinformasjon

Namn som er registrert i Cerebrum med språk, til dømes titlar til personar, eller namn og akronym for organisasjonsenhetar.

Ein har i tillegg til standardkonfigurasjonen valga:

• Namnevariantar: Ei prioritert liste over kva typar namn som skal hentast ut av Cerebrum.

  Døme: Langt namn, kort namn, visingsnamn, akronym, personleg tittel, arbeidstittel.

• Språk: Ei prioritert liste over kva språk som skal brukast.

  I tilfeller der både namnevariantar og språk inneheld fleire element, vil ein for kvar namnevariant prøve alle språka før ein eventuelt leiter gjennom neste namnevariant.

  Døme: Norsk, engelsk.

2.6   Adresser

Adresser registrert for entitetar.

Merk at adresser består av fleire element, som gateadresse, postnummer, stad, land med meir, så her må formatet definerast i konfigurasjonen med Transform.

Ein har i tillegg til standardkonfigurasjonen valga:

• Adressetypar: Ei prioritert liste over typene adresser som skal brukast.

  Døme: Postadresse, privat adresse, street (kontoradresse), annet.

2.7   Ekstern ID

Eksterne identifikatorar som ligg lagra i Cerebrum, som til dømes identifiserer personar i kjeldesystema.

Ein har i tillegg til standardkonfigurasjonen valga:

• ID-typar: Ei prioritert liste over kva typer identifikatorar som skal brukast.

  Døme: fødselsnummer, SAP-ID (ansattnummer), studentnummer, SID frå AD eller GUID frå AD.

Merk: Vi fraråder å overføre fødselsnummer, då ein bør bruke dette i minst mogeleg grad. Om ein treng ein unik identifikator finnast det andre, bedre identifikatorar, inkludert Cerebrum sin entity_id som er unik for kvar entitet.

2.8   Trait

Traits som er lagra i Cerebrum. Traits er generelle tagger som kan brukast til kva som helst der vi ikkje har ei generell løysing eller ein annan stad å lagre informasjon. Traits kan innehalde verdiar av typen streng, tal og datoar, så utsjånaden til attributtet bør konfigurerast med Transform.

Ein har i tillegg til standardkonfigurasjonen valga:

• Trait-typar: Ei prioritert liste over kva typer traits som skal brukast.

  Døme: trait for automatiske grupper, trait for reserverte brukarar, trait for om ein brukarkonto er ein gjestebrukar. Nokre instansar lagrer også kva som er HomeMDB for ein brukar i eit trait.

2.9   E-postadresser

Informasjon om e-postadresser som er lagra i Cerebrum sin e-postmodul. Merk at det skillast mellom primæradressa og alias-adresser. Ein må bruke Transform for å velge kva som skal leggast med i attributtet.

2.10   E-postkvoter

Informasjon om e-postkvoter som er lagra i Cerebrum sin e-postmodul. Det ligg lagra to felt, ein for softkvote og ein for hard kvote. Bruk Transform for å velge kva som skal leggast ved i attributtet.

2.11   E-postvidaresending

Informasjon om aktive vidaresendingar som er lagra i Cerebrum sin e-postmodul. Ein entitet kan ha registrert fleire vidaresendingsadresser på seg.

Merk at det er berre aktive vidaresendingar som vert brukt.

Ein entitet kan også ha vald å beholde ein lokal kopi. Dette registrerast ved at ein av vidaresendingsadressene er til ein av brukaren sine eigne e-postadresser som er registrert i e-postmodulen. Slike tilfeller bør ein kunne ta hensyn til.

2.12   Posix-verdiar

Entitetar som brukarar og grupper kan vere registrert med POSIX-data, til dømes GID, UID, shell, gecos og heimeområde. Dette kan brukast for instansar der det er behov for å kombinere UNIX- og Windows-miljø.

Sidan entitetar kan vere registrert med fleire ulike POSIX-verdiar, bruker vi Transform til å plukke ut det som skal brukast.

Merk at AD treng å oppdaterast med eit ekstra schema for å kunne ta i bruk enkelte posix-attributtar.

2.13   Heimeområder

Brukarar kan vere registrert med heimeområder som er knytta til diskar i Cerebrum. Kvart heimeområde er registrert med ein status, til dømes om heimeområdet er oppretta, arkivert eller om det er registrert ein feil ved det. Ein må bruke Transform for riktig format.

Ein har i tillegg til standardkonfigurasjonen valga:

• Spread for heimeområdet: Kvar brukar kan vere registrert med fleire typar heimeområde i ulike system, til dømes ein path for UNIX-miljø og ein path for AD-miljø. Dette valget styrer kva heimeområde som skal brukast.

2.14   Gruppemedlemmer

Ved AD-synkronisering av grupper kan det være behov å liste gruppemedlemmer, som har sin egen registrering i AD. Det listes full path i AD for slike medlemmer av grupper. En må bruke Transform for riktig format.

Ein har i tillegg til standardkonfigurasjonen valga:

• Spread for medlemmer: Dette valget styrer hvilke spread gruppemedlemmer må for å bli listet. Alle spread som brukes her må ha egen AD-synkronisering definert i konfigurasjonen.
• Inkluder personer: Dette valget bestemmer om personmedlemmer av grupper skal være med i synken, om deres primærkontoer har nødvendig spread. Det er primærkontoer som blir listet som gruppemedlemmer i denne tilfelle.

Gruppemedlemskap hentast rekursivt. Dersom ei gruppe inneheld undergrupper som medlem, vert også desse lagt til som medlem i AD dersom dei også har riktig AD-spread. Dersom ei slik undergruppe ikkje har AD-spread, vil undergruppa sine medlem bli lagt til dersom dei har AD-spread. Medlemskapa vert i slike situasjonar "dytta oppover".

4.1   Generelle attributt

Døme på attributtar som gjeld for alle typar entitetar og objekt:

• SAMAccountName: Settast til entity_name. Vert påvirka av definert namneformat. Dette attributtet brukast som identifikator av synken og bør ikkje endrast.
• Name: Settast til entity_name. Vert påvirka av definert namneformat.
• DistinguishedName: Settast til CN=entity_name etterfølgd av definert OU. Dersom eit objekt ligg i ein annan OU kan det bli flytta om konfigurasjonen seier det. CN vert påvirka av definert namneformat. Dette attributtet brukast i visse tilfeller som identifikator av synken, så ein bør ikkje flytte objekt som Cerebrum skal synkronisere, då det vil kunne føre til at objektet ikkje vil bli oppdatert.
• UserPrincipalName: Settast til entity_name@domene. Vert påvirka av definert namneformat.
• MailNickname: Kan settast til entity_name. Vert påvirka av definert namneformat. Dette kan brukast av til dømes brukarar og distribusjonsgrupper.

4.2   Brukarar

Døme på attributtar som gjeld for alle brukarobjekt:

• Enabled: Vert enabled berre dersom brukaren ikkje har ein passert expire_date eller er i karantene.
• DisplayName: Settast til fornamnet og etternamnet til personen som eig brukaren, skild med eit mellomrom. Feltet er tomt dersom brukaren eigast av ei gruppe. Namnet vert henta frå Cached.
• GivenName: For personlege brukarar settast dette attributtet til fornamnet til personen som eig brukaren. Namnet vert henta frå Cached.
• Surname: For personlege brukarar settast dette attributtet til etternamnet til personen som eig brukaren. Merk at dette attributtet er det samme som Sn i AD. Namnet vert henta frå Cached.
• Title: Tittelen til personen som eig brukaren. Feltet er tomt dersom brukaren eigast av ei gruppe. Det kan definerast kva tittel som skal ha prioritet, til dømes mellom personleg tittel og arbeidstittel.
• Mail: Settast til personen si primære e-postadresse. Dersom instansen bruker e-mail-modulen hentast adressa ut derfrå, hvis ikkje hentast e-postadressa som er lagra som kontaktinfo av typen EMAIL for enten personen eller brukaren.
• TelephoneNumber: Settast til kontakttypen PHONE registrert på person eller brukar.
• Mobile: Settast til kontakttypen MOBILE registrert på person eller brukar.
• EmployeeNumber: Vil inneholde SAP-id for dei som har det registrert på personen. Det er ikkje blitt implementert å kunne endrast til andre kjeldesystem, men det er ei enkel sak å fikse.
• StreetAddress: Gateadressa til ein av adressene som er registrert på personen.
• PostalCode: Postnummeret til ein av adressene som er registrert på personen.
• L: Poststad, som registrert i ein av adressene som er registrert på personen.
• Co: Land, som registrert i ein av adressene som er registrert på personen.

4.3   Grupper

Attributtar som gjeld for alle gruppeobjekt:

• Description: Settast til beskrivelsen av gruppa frå Cerebrum. Dersom dette ikkje eksisterer kan attributtet settast til "N/A".
• DisplayName: Settast til gruppenamnet. Vert påvirka av definert namneformat.
• DisplayNamePrintable: Settast til gruppenamnet. Vert påvirka av definert namneformat. Det er ingen skilnad på dette feltet og DisplayName.

4.4   PosixBrukarar

Posixbrukarar arver frå brukar-objekt, og definerer nokre nye attributtar:

• uidNumber: Settast til posixbrukaren sin POSIX UID.
• gidNumber: Settast til posixbrukaren si standard filgruppe sin GID.
• DisplayName: For upersonlege brukarar kan ein her bruke gecos, alternativt berre brukarnamnet.

4.5   Exchange

Exchange brukast på ulike måtar av instansane, og attributta som trengs varierer mellom versjonane av Exchange. Vi har difor ikkje ei komplett liste over attributtar som trengs av Exchange.

Nokre attributtar som brukast for Exchange:

• MailNickname: Settast likt brukarnamnet eller gruppenamnet. Vert påvirka av definert namneformat.
• Mail: Settast etter formatet gruppenamn@domene. Vert påvirka av definert namneformat. Dette attributtet kan bli overstyrd dersom gruppa har eit mailtarget knytta til seg, som då kan ha ei anna primæradresse.
• ProxyAddresses: Inneheld ei liste over e-postadresser, der primæradressa settast til SMTP:e-postadresse etterfølgd av alias på formatet smtp:e-postadresse.
• TargetAddress: Kan settast til primær e-postadresse.
• MsExchPoliciesExcluded: Kan styre standardverdiar i Exchange-miljøet, og inneheld til dømes "{26491cfc-9e50-4857-861b-0cb8df22b5d7}".
• HomeMDB: Set kva maildatabase objektet har e-posten sin på.
• MDBStorageQuota, MDBOverQuotaLimit og MDBOverHardQuotaLimit: Set kvotene på objektet sin maildatabase.