AD indlæsningsintegration

AD indlæsningsintegration indlæser brugeroplysninger fra Active Directory ind i SOFD Core. Dette dokument beskriver installation og konfiguration.

Forudsætninger#

Windows Server#

Servicen skal installeres på en Windows maskine med:

• Netværksmæssig adgang til kommunens AD
• Netværksmæssig adgang til SOFD Core i skyen via HTTPS.
• .NET Framework 4.6.1 eller nyere

Service konto i AD#

Der skal oprettes en service konto i kommunes AD.

Kontoen skal have læseadgang til alle de bruger-attributter der skal læses fra brugerkonti inkl. den attribut som indeholder brugerens cpr-nummer.

Endelig skal systembrugeren også have rettighed til at replikere data fra Active Directory. Det har en domæneadministrator automatisk, men det anbefales i stedet at tildele den enkelte replikeringsrettighed direkte til service kontoen via nedenstående vejledning.

1. Åben “Active Directory Users and Computers” konsollen
2. Vælg domænet, højreklik, og vælg “Properties”.
3. Gå til “Security”-fanen og tilføj systembrugeren.
4. Sæt rettigheden Replicating Directory Changes til “Allow”.

Replicating Directory Changes er i udgangspunktet den eneste replikeringsrettighed der skal tildeles. Det gælder også når cpr-attributten er markeret confidential, som anbefalet i afsnittet Afklaring af cpr-attribut.

Der findes en yderligere replikeringsrettighed, Replicating Directory Changes In Filtered Set, som kun er nødvendig i det tilfælde der er beskrevet herunder. Den bør kun efterspørges når den faktisk er nødvendig, da den indgår i kendte angreb mod domænet og mange kommuners sikkerhedsafdeling derfor ikke tillader den.

Replicating Directory Changes In Filtered Set er nødvendig hvis en af de attributter der skal synkroniseres har talværdien 512 med i sin searchFlags-værdi i AD-skemaet. Langt de fleste attributter har den ikke, så værdien bør slås op før rettigheden efterspørges.

De 512 markerer at attributten ikke må replikeres ud til en skrivebeskyttet domænecontroller, altså den type domænecontroller nogle kommuner placerer på lokationer hvor den fysiske sikkerhed er dårlig. I Microsofts dokumentation hedder listen over den slags attributter “RODC filtered attribute set”. Nogle kommuner sætter flaget på cpr-attributten netop for at holde cpr-numre væk fra de udsatte servere.

Værdien 512 forveksles let med de 128 der markerer attributten som confidential. De to har hver sin betydning, og kun 512 kræver denne rettighed. Er begge sat, står der 640 i searchFlags.

Den faktiske værdi for en attribut kan læses sådan. Bemærk at der skal filtreres på lDAPDisplayName, da attributten hedder noget andet i skemaet (attributten employeeNumber ligger på skema-objektet Employee-Number).

Get-ADObject -SearchBase (Get-ADRootDSE).schemaNamingContext -LDAPFilter "(lDAPDisplayName=employeeNumber)" -Properties lDAPDisplayName,searchFlags | Select-Object Name,lDAPDisplayName,searchFlags

Er de 512 sat, findes attributten slet ikke på de skrivebeskyttede domænecontrollere. Læser integrationen fra en af dem, kan attributten derfor ikke hentes uanset hvilke rettigheder service kontoen har, og integrationen skal i stedet pege på en almindelig, skrivbar domænecontroller.

Bemærk at der kan gå nogle minutter fra en rettighed er sat, til den slår igennem. Hvis man under kørsel af softwaren får “Access Denied” i loggen i kaldet til Active Directory, så er det disse synkroniseringsrettigheder der mangler.

Rettigheden Replicating Directory Changes All skal ikke tildeles. Den dækker Active Directorys hemmelige attributter, som er en fast liste af attributter med adgangskoder og trust-oplysninger, og de indlæses ikke af denne integration. Er rettigheden tildelt ved en tidligere installation, kan den fjernes igen.

API bruger til SOFD Core backend#

Der skal i konfigurationen indtastes et brugernavn og kodeord. Disse udleveres af Digital Identity.

Afklaring af cpr-attribut#

Det skal afklares hvilken attribut i AD der indeholder/skal indeholde brugerens cpr-nummer. Det kan eksempelvis være attributten EmployeeNumber.

Det anbefales at den valgte attribut skjules for almindelige brugere ved at tilføje confidentiality bit på attributten. Bemærk at det ikke er alle felter i AD der understøtter denne mulighed.

Dette kan f.eks. gøres via ADSI Edit MMC snap-in ved at tilføje bit 8 (tal-værdi 128) til searchFlags på attributten. Bemærk at hvis searchFlags har en værdi i forvejen, og den ikke i forvejen har bit 8 sat, skal bit 8 (tal-værdi 128) lægges til denne værdi.

Med dette flag sat er det kun brugere med CONTROL_ACCESS rettighed i AD, der kan læse/skrive attributten (default administratorer).

Service kontoen skal derfor også have Read Property og CONTROL_ACCESS på netop denne attribut. Rettigheden gives afgrænset til den enkelte attribut, og der er ikke behov for yderligere replikeringsrettigheder.

dsacls "DC=kommune,DC=dk" /I:S /G "KOMMUNE\sofdservice:RPCA;employeeNumber;user"

Den valgte attribut til cpr-nummer angives i indstillingen ActiveDirectory.Property.Cpr under konfiguration i det næste afsnit af denne vejledning.

Afklaring af affiliation-attribut#

Det er muligt at lade Active Directory være master for et organisatorisk tilhørsforhold til den autoritative organisation i SOFD Core.

Normalt defineres dette tilhørsforhold via en integration til f.eks. lønsystemet, men der kan være brugere som kun findes i Active Directory, men hvor man alligevel ønsker at indplacere dem organisatorisk. Det kan eksempelvis være eksterne konsulenter.

Hvis man ønsker denne funktionalitet, kan man i indstillingen ActiveDirectory.Property.Affiliation angive navnet på en AD attribut. Brugere hvor der i denne attribut står en værdi der matcher et masterId fra lønsystemet (LOS ID), vil få oprettet et organisatorisk tilhørsforhold til den tilsvarende organisatoriske enhed i SOFD Core.

Installation af Windows Service#

Der skal installeres og konfigureres en Windows Service på en server hvor der er netværksmæssig adgang til kommunens AD samt SOFD Core i skyen via HTTPS.

Download service#

Hent installeren via download-linket øverst på siden eller fra den samlede Download-oversigt.

Konfiguration af service#

Konfiguration af servicen foretages i appSettings sektionen i xml-filen SOFDCoreAD.Service.exe.config som ligger i roden af installationsmappen (default C:\Program Files (x86)\Digital Identity\SofdCoreADEventDispatcher).

De indstillinger der skal konfigureres under en standardinstallation er fremhævet med gult (markeret med * i tabellen nedenfor).

Skal OS2sofds genaktiverings-flow (Reaktiver-ordrer) bruges, skal deaktiverede AD-konti også indlæses. Sæt ActiveDirectory.TreatDisabledAsEnabled til True, så deaktiverede konti synkroniseres til SOFD Core. Ellers kan OS2sofd ikke danne reaktiverings-ordrer for genansatte.

Såfremt ActiveDirectory.IntegratedSecurity er sat til “true” i xml-konfigurationen skal service kontoen angives på “Log On” fanen i Windows Services.

På “Log On”-fanen vælges “This account”, og domænekontoen (fx domain\sofdservice) angives med tilhørende password.

Start af service#

Efter servicen er konfigureret startes den via Windows Services eller tilsvarende kommandolinjeværktøjer.

Servicen hedder “SOFD Core AD Event Dispatcher” i Windows Services.

Ved start/genstart af servicen foretages altid en fuld synkronisering.

Det er derfor en god idé at kigge i logfilen om alt er gået godt. Logfilens placering kan ses i indstillingen serilog:write-to:RollingFile.pathFormat.

Logfilen bør få sekunder efter opstart indeholde 3 linjer der ser nogenlunde sådan her ud:

2019-09-04 06:00:04 [Information] [SOFDCoreAD.Service.Job.SynchronizeJob] Performing full sync
2019-09-04 06:00:06 [Information] [SOFDCoreAD.Service.ActiveDirectory.ActiveDirectoryService] Found 4860 users in Active Directory
2019-09-04 06:00:12 [Information] [SOFDCoreAD.Service.Job.SynchronizeJob] Full sync complete

Ændringslog#

Ændringslog for AD indlæsningsintegration. Nyeste version øverst.