Eksisterande funksjonalitet i Cerebrum for e-post og Exchange

Ei utgreiing om kva som eksisterer i Cerebrum av funksjonalitet som kan vere relevant for ny synk mot Exchange på UiO. Dette dekker både E-postmodulen i Cerebrum og kva andre instansar har av synk mot AD og Exchange.

Dette dokumentet skal brukast som grunnlag for å kunne spesifiser kva som trengs av endringar for å støtte bruk av Exchange 2013 for brukarar, og gå frå bruk av Cyrus.

1   Oversikt

Kva vi har av funksjonalitet i Cerebrum som er relevant for synk mot Exchange:

  • E-postmodulen, som brukast for å lagre e-postinformasjon i Cerebrum.
  • BofhdRequest, som oppdaterer Cyrus med endringar i e-postinformasjon.
  • Mixins for e-postmodulen, spesielt det som brukast av UiO, som oppdaterer e-postinformasjon og lager BofhdRequests for å oppdatere e-postsystemet.
  • UiA sin AD-synk, som bruker e-postmodulen og synker mot Exchange for UiA. Det finnast også andre AD-synkar for andre instansar, men dei bruker e-postmodulen, og Exchange, i mindre grad, så dei er ikkje så interessante i denne samanhengen.
  • Mail-LDIF, som oppdaterer MX-en med informasjon om e-postadresser.
  • Org-LDIF, som oppdaterer person/organisasjonstreet. Denne har informasjon om primæradressa til personar.
  • Bofh-kommandoar, for å administrere e-postinformasjon og Cyrus.
  • TODO: skript for å oppdatere e-postrelatert informasjon, andre synkar?

2   E-postmodulen

Cerebrum har ein eigen modul for Email, som vart utvikla for at Cerebrum skal kunne ta seg av e-postdata for Cerebrum-entitetar, som brukarar. Modulen er i bruk for UiO og UiA, men eit utplukk av funksjonaliteten brukast også av andre Cerebrum-instansar. Modulen er bygd for å støtte UiO sine ulike domener og innstillingane til kvar av desse, og også andre UiO-innstillingar for spam, filter og vidaresendingar.

Det mest grunnleggande av funksjonaliteten i e-postmodulen består av:

2.1   EmailTarget

EmailTarget er eit samlepunkt for å knytte ein entitet, til dømes ein brukar, opp mot sine e-postadresser. EmailTarget, heretter kalla target, er i seg sjølv også ein entitet i Cerebrum. Alle targets kan registrerast opp mot ein server, som er maskina som tek seg av innboksen til entiteten.

Eit target har knytta til seg:

  • target_id: Primærnøkkelen, er target sin entity_id.

  • target_type: Kva type target det er snakk om:

    • multi: Ein target som skal sendast til fleire, andre targets.
    • account: Vanlege brukarar.
    • deleted: For entitetar som er expired, men som framleis treng å beholde adressene sine, spesielt vidaresendingsadressa eller for å gje ei feilmelding om at ei adresse ikkje er i bruk.
    • sympa: For e-postlister i Sympa.
    • mailman: For mailman-lister.
    • RT: For RT sine e-postlister.
    • forward: For targets som er reine vidaresendingar.
    • file og pipe: For lagring til ei fil eller ein shell pipe.

  • target_entity_id og target_entity_type: Kva entitet targetet er knytta opp mot.

  • alias_value: Kort fritekst som brukast til å spesifisere fil eller kommando for pipe, RT eller Sympa.

  • using_uid: Posixbrukaren sin UID. Brukt for account, forward og pipe, men set også kva brukar som skal køyre kommandoen for td. RT-e-post.

  • server_id: Set kva e-postserver som skal brukast, og peiker til EmailServer og då også eit vanleg Host-objekt i Cerebrum, som inneheld bl.a. hostname.

2.1.1   Referering

Det er i praksis ei ein-til-ein-kobling mellom brukarar og targets i dag.

  • Eitt target kan berre knyttast mot ein entitet. Det er likevel mulig å omgå dette med target av typen multi, som kan delegere e-post til andre entitetar.

  • Ein entitet kan ha meir enn berre eitt target knytta opp mot seg, på databasenivå, med unntak av at brukaren kan berre ha eitt target på ein server. Det er likevel ikkje støtte for det gjennom API-et, då det er ei forventing om at ein entitet skal berre få returnert eitt target frå databasen. Fleire rader vil kaste exceptions. Du vil til dømes ikkje kunne endre account_type for ein brukar utan at det feiler, dersom brukaren har fleire targets registrert på seg.

    Det er usikkert kor mange endringar som krevast for å kunne registrere fleire targets mot ein entitet, men det er snakk om å endre API-et, som vil påvirke omtrent all funksjonalitet som bruker e-postmodulen for å finne eller oppdatere enkeltbrukarar sin e-postinformasjon. find()-metodane vil måtte trenge ein ekstra variabel, som vi ikkje har i dag, for å finne ut kva target som skal hentast ut for ein gitt brukar. Databasen vil kanskje også måtte utvidast, for å kunne skille, sortere og/eller prioritere targets for brukaren.

2.2   EmailDomain

Eit objekt for å lagre informasjon om eit e-postdomene. Alle e-postadresser må vere tilknytta eit domene, til dømes uio.no eller student.hf.uio.no.

Informasjon som er knytta til domenet:

  • domain_id: Primærnøkkel.
  • domain: Fritekstfelt for FQDN. Kan vere på opp til 128 teikn, og må vere unikt.
  • description: Beskrivelse av kva domenet er.

Alle domener kan vere tilknytta ein fleire domene-kategoriar, som set innstillingar for domenet, spesielt i bruken av adresser, om ein brukar skal få adresse på formatet brukarnamn@domene, eller med fullt namn.

  • cnaddr: Fullt namn.
  • all_uids: Alle brukarar skal få ei adresse med brukarnamn som localpart i domenet.
  • noexport: Adressene under dette domenet skal ikkje eksporterast til e-postsystemet. Brukast for å sette opp eit domene før det takast i bruk.
  • uidaddr: Primæradressa for domenet skal ha brukarnamn som localpart.
  • UIO_GLOBALS: Brukast som override av localpart for alle domener med denne kategorien.

TODO: Kor og korleis registrerast affiliations opp mot eit domene? Kun i python-koden?

2.3   EmailAddress

Kvar einaste e-postadresse registrerast som ein EmailAddress og er tilknytta eitt domene. Alle e-postadresser knyttast også mot eitt EmailTarget for å registrere kva entitet adressa gjeld for, til dømes ein brukarkonto, men det er også mulig å registrere ei adresse mot eit multi-target for å knytte ei adresse mot fleire brukarar. Kvar e-postadresse er ein entitet i Cerebrum.

2.4   EmailServer

Ein EmailServer er ein subklasse av ein vanleg Host i Cerebrum, men med eitt ekstra felt, email_server_type, som seier kva type email-server det er:

  • cyrus_IMAP: Server is a Cyrus IMAP server, which keeps mailboxes in a Cyrus-specific format.
  • nfsmbox: Server delivers mail as mbox-style mailboxes over NFS.
  • sympa: Server is a Sympa mailing list server.
  • exchange: Exchange server.

Hostname ligg naturlegvis i Host-objektet.

Merk at det ikkje vil vere mulig å ha to forskjellige typar mailserver på samme hostname, slik dette er strukturert.

2.5   EmailPrimaryAddressTarget

Eit target kan settast opp med ei primær e-postadresse. På databasenivå er dette ganske enkelt ein tabell for EmailPrimaryAddress, som lenker frå ein EmailTarget til ei EmailAddress. Eit target kan difor også eksistere med adresser, utan at det eksisterer ei primæradresse for den.

For UiO vil primæradressa vere den adressa som står som avsendar når brukarar sender ut e-post. Denne oversettinga gjerast av MX-en.

2.6   Andre klassar

Det er fleire klassar i Email-modulen som referer til EmailTarget:

  • EmailQuota: Targets kan ha ei kvote på kor mykje plass innboksen kan ta opp før det er fullt. Kvoter knyttast til EmailTarget. Du har to kvoter, quota_soft og quota_hard, som brukast ulikt.
  • EmailTargetFilter: Targets kan settast opp med ulike filter som kan settast av eller på, som er innstillingar for spesielle eigenskaper, til dømes grålisting og uioonly. Kvart filter er ein eigen konstant.
  • EmailSpamFilter: Spam-innstillingar for eit target. Det er to innstillingar, spam_level (kor streng filtreringa skal vere) og spam_action (kva som skal gjerast med spam), begge er konstantar.

  • EmailVirusScan: Innstillingar for virussjekk for eit target. Har innstillingane virus_found_act, virus_removed_act og virus_enable.

    Merk at denne funksjonaliteten er ikkje i bruk på UiO idag.

  • EmailForward: Innstilling for om eit target skal vidaresende all e-post til ei anna e-postadresse. Vidaresendingsadressa er eit fritekstfelt, då dette kan vere eksterne e-postadresser. Har innstillingane enable, som seier om vidaresendinga er aktiv eller ikkje, og forward_to, som er eit fritekstfelt på 256 teikn for adressa som det skal vidaresendast til.

  • EmailVacation: Eit target kan settast opp med feriemeldingar eller tripnotes som automatiske svar i ein gitt periode. Kvar melding har ein start- og sluttdato, og kan slåast av og på.

3   BofhdRequest

BofhdRequest er funksjonalitet for å kunne køyre oppgaver som tek for lang tid til å kunne bli eksekvert av bofhd eller andre tenester. Eit døme er å snakke med Cyrus om flytting av mailboksar. Alle requests leggast i ei kø i Cerebrum, og vert deretter eksekvert av process_bofhd_requests ved neste køyring. For e-postrelaterte oppgaver vert jobben køyrd 2 minuttar etter forrige køyring, for andre oppgaver er dette 5 minuttar.

Oppgavene til BofhdRequest er å oppdatere karantener og arkivere og flytte heimeområder. For e-postrelaterte oppgaver er det:

  • Opprette mailboks, ved å snakke med Cyrus.
  • Sette/oppdatere e-postkvoter, ved å snakke med Cyrus.
  • Markere mailboks som sletta., ved å snakke med Cyrus.
  • Opprette ei sympa-liste. Sympa vert ikkje nemnd vidare, sidan e-postlister ikkje vert påvirka av NIKE-prosjektet.
  • Fjerne ei sympa-liste. Sympa vert ikkje nemnd vidare, sidan e-postlister ikkje vert påvirka av NIKE-prosjektet.

Oppdateringar mot Cyrus gjerast via IMAP4 gjennom SSL. Funksjonaliteten:

  • Opprettinga av ein mailboks gjerast ved å opprette mapper på formatet user.USERNAME.MAPPE, til dømes user.jokim.Sent og user.jokim.Drafts.
  • Sletting av ein mailboks gjerast ved å først arkivere e-posten med eit skript archivemail, for deretter å slette kvar mappe i mailboksen.
  • Kvoter settast berre med ein IMAP-kommando.
  • Flytting av mailboksar frå ein server til ein annan:
    1. Jobben sjekker at e-postleveringa er stoppa før brukaren kan flyttast. Dette gjerast ved at mail-LDAP må ha mailPause satt til TRUE, som kan settast gjennom bofh, og er noko vi oppdaterer ved å sende ein LDAP-kommando direkte til LDAP-tenaren. Eg gjetter på at MX-en sjekker dette før den leverer e-posten, og legger den evt. i kø.
    2. Kvota vert slått av, så dette ikkje vil kunne skape problem for flyttinga.
    3. Vi køyrer skriptet imapsync som ligg på mailserveren.
    4. Sieve-filter vert kopierte med eit skript managesieve_sync.
    5. Kvota settast tilbake til original verdi.
    6. EmailTarget oppdaterast til å peike på ny mailserver.

4   Mixins for e-postmodulen

E-postmodulen brukast som mixin for entitetar, og som inneheld meir funksjonalitet og bruk av Email-klassane.

  • Brukarar: Funksjonalitet for å oppdatere e-postadresser basert på account_types og algoritmer for å lage localpart basert på fullt namn. Kvar gang ein brukar får oppdatert ein account_type vert adressene gjennomgått og eventuelt oppdatert.

    Merk at dei fleste instansar overstyrer mykje av denne funksjonaliteten til eigne tilpassingar, så det er litt uoversikteleg kva som er endra og kvifor hos instansane. Det er ikkje blitt sett på i denne runden.

  • Kvote for brukarar: Ein eigen mixin for å støtte funksjonalitet for å oppdatere e-postkvoter for brukarar, basert på account_type og kva cereconf set av standardverdiar.

  • Personar: Mixin for person-objekt for å forenkle oppdatering av personen sine brukarar sine e-postinnstillingar. Når ein person endrar namn kan alle brukarane til personen bli gjennomgått for eventuelle endringar i e-postadresser.

4.1   UiO sine mixins for e-postmodulen

UiO har nokre lokale tilpassingar av Email-modulen:

  • Brukarar:
    • add_spread: Når ein brukar får IMAP-spread vert det oppretta eit target dersom det ikkje allereie eksisterer. Alle e-postinnstillingar vert oppdaterte, sidan gamle innstillingar kan eksistere i targetet og vere feil. Det som oppdaterast:
      • Kva server som brukast. Gjerast i _UiO_update_email_server, som legg inn BofhdRequest for å endre dette, som då også snakker med Cyrus om oppretting eller migrering. Ein mailboks vil enten bli oppretta eller eventuelt flytta om brukaren hadde ein mailboks på ein tidlegare mailserver. Dette gjeld også får targets markert som deleted.
      • Kvoter. Cyrus må bli informert om dette.
      • Spam-innstillingar, som hentast frå cereconf.
      • Filter. Henter standardfilter frå cereconf.
      • E-postadresser.
    • delete_spread: Dersom eit IMAP-spread vert fjerna vert Cyrus informert om det gjennom ein BofhdRequest for å markere mailboksen som sletta.
    • update_email_addresses: Prøver å bruke PosixUser dersom brukaren også er ein posixbrukar, for å kunne hente ut gecos. Oppdaterer også mailserver og kvoter.
  • TODO

5   UiA sin AD-synk

UiA har to AD-synkar som kan vere relevante for oss, ein for e-postlister som Contact, og ein for distribusjonsgrupper. Begge bruker e-postmodulen i Cerebrum.

5.1   Contactsync

Synken av Contacts henter ut alle targets frå e-postmodulen med target-type Mailman.

Nokre merknader:

  • Alle listene får attributtet Name satt til ein prefiks mailman. etterfulgd av full, primær e-postadresse. Dette gjeld for alle Mailman-targets.

  • UiA synker i dag over attributtane:

    • displayName: Settast til: "Epostliste - FULLEPOSTADRESSE".
    • targetAddress: Settast til: "SMTP:FULLEPOSTADRESSE".
    • proxyAddresses: Settast til ei liste på eitt element: "SMTP:FULLEPOSTADRESSE".
    • mail: Settast til full e-postadresse.
    • mailNickname: Settast til "mailman." etterfulgt av e-postadressa, men der krøllalfa er bytta ut med eit punktum.
    • msExchPoliciesExcluded: Settast til ein cereconf-variabel, som er {26491cfc-9e50-4857-861b-0cb8df22b5d7}.
    • msExchHideFromAddressLists: Settast til False.

  • E-postlister med ein localpart som er lenger enn 51 teikn (under 64 med prefiks, Exchange trengde visst kortare lengder) vert ignorert i synken.

  • Dersom det finnast e-postlister med namn x, men også x-admin og x-request vert dei to sistnemnde ignorert i synken.

5.2   Distribusjonsgruppesynk

Det er nokre grupper som skal brukast for Exchange. Alle slike grupper gjenkjennast ved at dei har eit spread til Exchange i tillegg til å ha eit spread til AD. Grupper som starter på fwd- vert også ignorerte, då dette tolkast som forward-grupper som brukast i brukarsynken til UiA.

Merk også at

Grupper får standard-attributta:

  • displayName og displayNamePrintable: Settast til gruppenamnet.
  • description: Settast til gruppa sin description frå Cerebrum, eventuelt "Not available".
  • msExchPoliciesExcluded: Settast til ein cereconf-variabel: {26491cfc-9e50-4857-861b-0cb8df22b5d7}.
  • msExchHideFromAddressLists: Settast til False.
  • groupType: Alle grupper vert universal security group.

Dersom ei gruppe skal til Exchange oppdaterer den:

  • proxyAddresses: Settast ei liste på eitt element: SMTP:GRUPPENAMN@uia.no, der domenet ligg i ein cereconf-variabel.
  • mailNickname: Settast til gruppenamnet.
  • mail: Settast til GRUPPENAMN@uia.no, der domenet ligg i ein cereconf-variabel.

5.3   Brukarsynk

Brukarsynken til UiA er utvida med funksjonalitet som er relevant for NIKE-prosjektet.

Av e-postinformasjon som hentast ut settast attributta:

  • mail: Settast til primæradressa til brukaren dersom brukaren skal til IMAP eller Exchange. Her brukast metoden getdict_uname2mailaddr som bruker e-postmodulen.
  • proxyAddresses: Settast til ei liste med alle e-postadressene til brukaren. Det første elementet inneheld primær e-postadresse på formatet "SMTP:EPOSTADRESSE", medan dei etterfølgande adressene får "smtp:ALIAS".
  • msExchHomeServerName: Settast til ein cereconf-variabel: "/o=UiA/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=EXCHGRM02".
  • homeMDB: Henter ut ein verdi frå eit trait exchange_mdb, og set det til: "CN=TRAITVERDI,CN=Databases,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=UiA,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=uia,DC=no"". Døme på kva traitet kan innehalde: "MailboxDatabase03".
  • mDBOverHardQuotaLimit: Settast til EmailQuota sin hardquota eller ein standardverdi på 200000 om det ikkje er satt. Verdien multipliserast med 1024.
  • mDBOverQuotaLimit: Settast til EmailQuota sin softquota eller ein standardverdi på 150000 om det ikkje er satt. Verdien delast deretter på 100 og multipliserast med verdien for hardquota, som gir ein høg verdi.
  • mDBStorageQuota: Settast til 90% av mDBOverQuotaLimit.
  • mDBUseDefaults: Settast til False.
  • msExchHideFromAddressLists: Settast til False for primærbrukarar og True for alle andre.
  • msExchPoliciesExcluded: Settast til ein cereconf-variabel: {26491cfc-9e50-4857-861b-0cb8df22b5d7}.
  • deliverAndRedirect: Settast til True. Oppdaterast berre om "forwarding sync" er på.
  • userPrincipalName: Settast til brukarnamn etterfølgd av @uia.no.
  • mailNickname: Settast til brukarnamnet, men berre dersom brukaren skal til IMAP eller Exchange.
  • targetAddress: Settast til samme verdi som ligg i attributtet mail.

Brukarsynken har i tillegg noko den kaller "forwarding sync". Den henter då ut alle registrerte vidaresendingar frå EmailForward for dei brukarane som skal til AD og Exchange. Attributtet deliverAndRedirect settast til False, eventuelt til True dersom ein av dei registrerte vidaresendingsadressene allereie ligg i proxyAddresses (som i praksis vel betyr at brukaren vidaresender til seg sjølv).

For kvar brukar som har vidaresending opprettast eit objekt med attributtar:

  • Name: Settast til "Forward_for_USERNAME__FORWARDADDRESS".
  • targetAddress: Settast til SMTP:FORWARDADDRESS.
  • proxyAddresses: Settast til ei liste på eitt element: SMTP:FORWARDADDRESS.
  • mail: Settast til vidaresendingsadressa.
  • msExchPoliciesExcluded: Standard verdi.
  • msExchHideFromAddressLists: Settast til True.
  • mailNickname: Settast til "BRUKARNAMN_forward=FORWARDADDRESS", men der krøllalfa er bytta ut med eit punktum.
  • owner_uname: Settast til brukarnamnet. Obs: ikkje eit attributt, til intern bruk.

I tillegg henter brukarsynken ut nokre distribusjonsgrupper. Formålet med desse gruppene er å samle alle forwarding objects for ein brukar. For

Andre merknader til brukarsynken:

  • Dersom ein brukar ikkje lenger finnast i Cerebrum vert brukaren disabled i AD, men i tillegg vert også msExchHideFromAddressLists satt til True.

6   Bofh

TODO: Kva e-post-kommandoar er relevante?

TODO: Dette er ei liste over kommandoar som kan vere relevante. Sorter og kommenter kva som er relevant, evt. fjern det som ikkje er relvant.

  • email_add_address
  • email_remove_address
  • email_reassign_address
  • email_forward
  • email_add_forward
  • email_delete_forward
  • email_remove_forward
  • email_create_forward
  • email_info:
    • Utvid til å vise mdb for brukaren dersom serveren er exchange.
    • Utvid til å også kunne brukast for grupper. Det er ikkje sikkert at gruppenamn kan brukast, men at ein må oppgje ei full e-postadresse for å forenkle oppslaget.
    • Bør vise om targetet er cyrus eller exchange. Dette visast mest sannsynleg allereie i dag.
  • email_create_archive
  • email_delete_archive
  • email_mod_name
  • email_primary_address
  • email_create_pipe, email_delete_pipe, email_edit_pipe_user og email_edit_pipe_command: Det kan vere behov for å legge inn sjekkar her på om det eksisterer ei gruppe med samme namn.
  • email_failure_message
  • email_create_domain og email_delete_domain
  • email_domain_configuration
  • email_domain_set_description
  • email_domain_info
  • email_add_domain_affiliation og email_remove_domain_affilation
  • email_create_list og email_delete_list
  • email_create_sympa_list og email_delete_sympa_list
  • email_create_multi og email_delete_multi
  • email_create_sympa_cerebrum_list
  • email_create_list_alias og email_remove_list_alias
  • email_create_sympa_list_alias og email_remove_sympa_list_alias
  • email_reassign_list_address
  • email_rt_create og email_rt_delete
  • email_rt_add_address, email_rt_remove_address og email_rt_primary_address
  • email_migrate
  • email_move
  • email_pause
  • email_list_pause
  • email_quota
  • email_add_filter og email_remove_filter
  • email_spam_level og email_spam_action
  • email_tripnote, email_list_tripnotes, email_add_tripnote og email_remove_tripnote
  • email_update

7   Mail-LDIF

Cerebrum eksporterer for UiO metadata om e-post for brukarar og andre entitetar gjennom ei LDIF-fil, som brukast av LDAP. Denne brukast blant anna av UiO sin MX, og inneheld informasjon om alle e-postadresser som gjeld for kva entitet, kva server entiteten sin innboks ligg på, og andre innstillingar til dømes for spam, filter og vidaresending.

Eksporten henter ut alle EmailTarget frå Cerebrum, og ...

TODO

8   Org-LDIF

Organisasjonstreet bruker e-postmodulen for ... primæradresser... TODO

Av jokim
Publisert 6. sep. 2013 13:42
Del på e-post