Konfigurasjon av AD-synkroniseringa

2.1.1   Nødvendige instillinger

Disse parametrene må være definert i konfigurasjonen. Synken nekter å kjøre hvis noen av disse ikke er tilstede.

navn aka synktype

Navnet på et element i SYNCS-dictionary. For noen synkroniseringsklasser fungerer dette også som navnet på en spread som Cerebrum-entiteter må ha for å bli plukket opp av synken. I sånne tilfeller kan man spare å definere noen ekstra instillinger i selve synken med å bare bruke spreadnavn til synkenavn. Ellers er det bare en string.

Hvis navnet ikke samtidig definerer en spread, må synken ha target_type/target_spread-parametere definert.

Eksempel:

SYNCS['account@ad']
SYNCS['some_kind_of_sync']

domain

Navnet til AD-domenet.

Eksempel:

'domain': 'uio.no',

server

Navnet til AD-serveren

Eksempel:

'server': 'adhost.uio.no',

target_ou

Navnet til en organizational unit som skal inneholde AD-objekter som synkroniseres av synken. Nye objekter opprettes under denne OUen. target_ou må vise til veien som er samme som search_ou eller ligger under den.

Eksempel:

'target_ou': 'OU=Users,OU=UiO,DC=uio,DC=no',

search_ou

Navnet til en organizational unit som inneholder AD-objekter synken må ekstrahere fra serveren og sammenligne med Cerebrum data for å opprette nye/ender eksisterende/slette utdaterte AD-objekter. target_ou må ligge under denne parameteren. Dvs. at synkens søkeomfang kan inneholde flere steder enn bare det synken har lov til å opprette nye objekter i. I de fleste tilfeller viser likevel target_ou og search_ou til samme vei.

Eksempel:

'search_ou': 'OU=UiO,DC=uio,DC=no',

object_classes

Objektklasser som skal brukes av denne synken. Ut av alle klassene som er oppgitt her vil det bli konstruert en dynamisk klasse som representerer objekter som inneholder data som skal synkes. Den siste klassen er superklassen, de som kommer før er dens subklasser.

Eksempel:

'object_classes': (
    'Cerebrum.modules.no.hia.AD2sync/UiACerebrumUser',
    'Cerebrum.modules.ad2.CerebrumData/PosixCerebrumUser',
    'Cerebrum.modules.ad2.CerebrumData/MailTargetEntity',
    'Cerebrum.modules.ad2.CerebrumData/CerebrumUser',
    ),

Her er CerebrumUser superklasse, alle andre er dens subklasser.

2.1.2   Default instillinger

Disse instillingene får default verdi om de trenges av synken men ikke er definert tydelig i oppsettet.

dryrun

Hvis True, vil synken bare publisere i logfiler hva som ville skjedd på AD-servern uten å gjøre selve endringene. Synken krever likevel tilkobling til serveren for å ekstrahere data og sammenligne den med data i Cerebrum.

Default: False

Eksempel:

'dryrun': True,

encrypted

Definerer om tilkoblingen til AD-serveren er kryptert eller ikke.

Default: True

Eksempel:

'encrypted': True,

auth_user

Brukernavnet som trenges for autentifisering på AD-serveren

Default: cereauth

Eksempel:

'auth_user': 'aduser',

domain_admin

Navnet til domenet og brukernavnet til brukeren som kan administrere domenet.

Default: cerebrum_sync

Eksempel:

'domain_admin': 'UIO\\adadmin',

move_objects

Bestemmer om synken skal flytte til target_ou objektene som finnes utenfor det i AD. Hvis ikke True -- blir objektene oppdatert direkte der de ligger.

Default: False

Eksempel:

'move_objects': True,

subset

Inneholder en liste av navnene til AD-objektene. Bare objekter som har disse navnene blir endret, alle andre objekter ignoreres.

Default: None

Eksempel:

'subset': ['user1', 'user2', 'user3']

ad_admin_message

Hva skal synken gjøre med administrative AD-meldinger som den får fra serveren. De kan logges, sendes per email til oppgitte adresser eller skrives i en fil. Parameteren er en tuple og kan inneholde enter lister eller tupler som hver består av følgende elementer:

1. aksjon: mail, log, file eller None. Hva skal synken gjøre med meldinger

   • log: skjer faktisk ikke noe fordi alle meldingene blir logget by default
   • file: ikke implementert ennå

2. nivå: error, warning, info eller debug. Bare meldinger som er høyere eller på oppgitt nivå blir lagret og logget/sendt

3. E-mail adresser eller navnene til filer meldingene skal sendes/logges til. Ubegrenset antall

Default: ()

Eksempel:

'ad_admin_message': (['mail', 'error', 'admin1@usit.uio.no', 'admin2@adsync.uio.no'],
                     ['file', 'warning', '/tmp/warning_ad.log']),

name_format

Hvilket navn skal objekten få i AD. Navnet utgjøres ut av et internt navn objekten får fra Cerebrum (avhengig fra objektklasser som brukes i synkronisering). Denne parameteren kan være enten en string med formatteringen, der '%s' byttes med det interne objektsnavnet, eller en funksjonsnavn. Hvis det er funksjonen, vil den bli kalt med det interne navnet som eneste parameter. Funksjonen må være på forhånd definert i adconf.py eller andre filer som importeres av adconf.py, og må ta i mot en parameter. Formatteringen kan brukes for å legge til forskjellige suffikser og prefikser til det interne navnet, mens funksjonene kan brukes når det trenges mer kompliserte navnetransformasjoner.

Default: '%s'

Eksempel:

'name_format': 'prfx-%s_sfx',
'name_format': shorten_to_10_symbols_and_replace_dots,

ignore_ou

En list av navnene til organizational units som skal ekskluderes fra søk av AD-objekter.

Default: ()

Eksempel:

'ignore_ou': ['OU=OldUsers,OU=UiO,DC=uio,DC=no'],

create_ous

Tillate eller forby opprettelse av nye OUer, om de ikke eksisterer når synken skal opprette/flytte objekter.

Default: False

Eksempel:

'create_ous': True,

attributes

Kva attributtar som skal oppdaterast i AD. Detaljert beskrivelse av attributter ligger her

Default: {}

useraccountcontrol

Ikke implementert fullt ennå Gjelder bare for brukersynk, ignoreres i alle andre typer synk. En liste av innstillinger som definerer oppførselet til synkroniserte brukerkontoer. Les mer her

Default: {}

Eksempel:

'useraccountcontrol': ('HomedirRequired', 'PasswordNotRequired'),

store_sid

Om SID skal lagres i Cerebrum.

Default: False

Eksempel:

'store_sid': True,

handle_unknown_objects

Hva skal synken gjøre med objekter som er i AD, men ikke i Cerebrum. Man kan velge mellom ignore (ikke gjøre noe), disable (markere som disabled, funker bare for brukerkontoer), move (deaktivere og flytte til annen OU) og delete (slette sånne objekter). Parameteren er en tuple, der første element er aksjon. Den andre elementen er None eller veien til en OU hvis den første elemente er move.

Default: ('ignore', None)

Eksempel:

'handle_unknown_objects': ('move', 'OU=Deleted Users,OU=UiA,DC=nhn,DC=local'),
'handle_unknown_objects': ('delete', None),

handle_deactivated_objects

Samme som forrige parameter, men for deaktiverte objekter i AD.

Default: ('ignore', None)

language

Hvis attributten kan finnes i flere språk, definerer denne parameteren hvilke språk attributten kan hentes i. Parameteren er en tuple der elementer er to-bokstavers språkkonstanter fra Cerebrum.

Default: ('nb', 'nn', 'en')

Eksempel:

'language': ('nb', 'nn', 'en'),

changes_too_old_seconds

Gjelder bare hurtigsynken. Bare endringer som skjedde ikke tidligere enn for dette antall sekunder siden blir synkronisert.

Default: 60*60*24*365 (altså ett år)

Eksempel:

'changes_too_old_seconds': 3600,

group_type

Gjelder bare gruppesynk. Hva slags grupper blir synkronisert. Kan være enten security eller distribution.

Default: 'security'

Eksempel:

'group_type': 'distribution',

group_scope

Gjelder bare gruppesynk. Definerer rekkevidden til grupper som blir synkronisert. Kan være enten global eller universal.

Default: 'global'

script

Kjøre en skript på AD-serveren ved noen aksjoner. Skripter må være skapet på forhånd av AD-administratoren og ligge der det er oppgitt i parameteren. Synken fra Cerebrum side kan bare sende en signal om å kjøre en skript som ligger på et visst sted. Parameter er en dict, der hver element har en aksjonsnavn som nøkkel og veien til skripten som verdi. Aksjoner der en skript kan kjøres er new_object, delete_object, move_object.

Default: {}

Eksempel:

'script': {'new_object': '/tmp/script_for_new_objects',
           'move_object': '/usr/bin/move_object_script'},

ou_mappings

Liste som brukes til å angi organizational unit (OU) i AD basert på brukerens brukertilknytning(er), persontilknytning(er) og OU i Cerebrum.

ou_mappings har innvirkning kun på brukersynkronisering.

Hvert element i lista er en dictionary med to elementer:

• affiliations - liste av brukertilknytning/persontilknytning@CerebrumOU strenger (se eksempel!)
• ou - OU verdien som blir satt i AD dersom brukerens tilknytninger samsvarer én eller flere affiliations elementer.

ou_mappings lista sjekkes sekvensielt. Dersom affiliations til et element samsvarer brukerens eller personens tilknytninger (dette er en og-sjekk, så alle elementer må samsvare), vil tilsvarende ou verdi bli brukt i AD og ingen flere elementer vil bli sjekket.

Verdien til target_ou vil bli brukt dersom ingen element match'er brukerens tilknytninger eller ou_mappings ikke er satt.

Default: []

Eksempel:

'ou_mappings': [
    # alle som har brukertilknytning 'STUDENT'
    {'affiliations': ['STUDENT'],
     'ou': 'OU=studenter,OU=Cerebrum,DC=nmh,DC=int'
    },
    # alle som har brukertilknytning 'ANSATT',
    # persontilknytning 'tekadm' og tilhører OU 023100 OG 023200
    {'affiliations': ['ANSATT/tekadm@023100', 'ANSATT/tekadm@023200'],
     'ou': 'OU=Administrasjon,OU=Cerebrum,DC=nmh,DC=int'
    },
    {'affiliations': ['ANSATT'],  # alle som har brukertilknytning 'ANSATT'
     'ou': 'OU=Faglige Ansatte,OU=Cerebrum,DC=nmh,DC=int'
    }
]

Dypere eksempel, som illustrere og/eller funksjonalitet i definisjonen:

«ou_mappings» datastrukturen søkes gjennom linært, og første tilknytningskriterium som oppfylles blir brukt. I så måte utføres det en OR-evaluering mellom elementene i «ou_mappings». For hvert affiliation-kritrium i elementene i «ou_mappings», utføres det en logisk AND evaluering, mellom de forskjellige tilknytningene.

Følgelig vil:

'ou_mappings': [
  {'affiliations: ['STUDENT@008'],
   'ou': 'OU=min,OU=fine,DC=ou'},
  {'affiliations: ['ANSATT@007', 'STUDENT@007'],
   'ou': 'OU=min,OU=hemmelige,DC=ou'},
  {'affiliations': ['ANSATT']:
   'ou': 'OU=min,OU=ansatte,DC=ou'},
  {'affiliations': ['STUDENT']:
   'ou': 'OU=min,OU=student,DC=ou'}]

resultere i at en konto med:

• Brukertilknytning STUDENT får OU=min,OU=student,DC=ou
• Brukertilknytning ANSATT får OU=min,OU=ansatte,DC=ou
• Brukertilknytning ANSATT@007 OG STUDENT@007 får OU=min,OU=hemmelige,DC=ou
• Brukertilknytning STUDENT@008 får OU=min,OU=fine,DC=ou

Merk at hvis «ou_mappings» hadde sett slik ut:

'ou_mappings': [
  {'affiliations': ['ANSATT']:
   'ou': 'OU=min,OU=ansatte,DC=ou'},
  {'affiliations': ['STUDENT']:
   'ou': 'OU=min,OU=student,DC=ou'},
  {'affiliations: ['STUDENT@008'],
   'ou': 'OU=min,OU=fine,DC=ou'},
  {'affiliations: ['ANSATT@007', 'STUDENT@007'],
   'ou': 'OU=min,OU=hemmelige,DC=ou'}]

så ville:

• Brukertilknytning STUDENT få OU=min,OU=student,DC=ou
• Brukertilknytning ANSATT få OU=min,OU=ansatte,DC=ou
• Brukertilknytning ANSATT@007 samt STUDENT@007 få OU=min,OU=ansatte,DC=ou
• Brukertilknytning STUDENT@008 få OU=min,OU=student,DC=ou

2.1.3   Andre instillinger

sync_type

Navnet på annen synk. Da vil denne synken bruke samme synkroniseringsklasser som den oppgitte synken.

Eksempel:

'sync_type': 'account@ad',

sync_classes

Synkroniseringsklasser som skal brukes av denne synken. Ut av alle klassene som er oppgitt her vil det bli konstruert en dynamisk klasse som utfører selve synken. Den siste klassen er superklassen, de som kommer før er dens subklasser.

Eksempel:

'sync_classes': (
    'Cerebrum.modules.ad2.ADSync/ProxyAddressesCompare',
    'Cerebrum.modules.ad2.ADSync/UserSync',
    'Cerebrum.modules.ad2.ADSync/MailTargetSync',
    ),

Her er MailTargetSync superklasse, UserSync og ProxyAddressesCompare er dens subklasser.

change_types

Gjelder bare hurtigsynken. Definerer hva slags endringar som skal behandlast av hurtigsynken. Dette må kunne spesifiserast per jobb, til dømes passord for passordsynken og alt relatert til grupper for ein hurtiggruppesynk.

Eksempel:

'change_types': (('account_password', 'set'),
                 ('ad_attr', 'add'),
                 ('ad_attr', 'remove')),