Oppsett av AD-synken for Windows-sida

Oversikt og beskrivelse av kva som trengs å gjerast på Windows- og AD-sida for at Cerebrum kan integrere med AD. Inneheld både forberedingar og innstillingar for AD-domenet og oppsett av Windows-maskin som Cerebrum skal snakke med.

1   Oppsummering

Kva som trengs før ein begynner på oppsettet:

  • Alle OU (organisatoriske enhetar) i AD som Cerebrum skal administrere må vere rydda opp i. Cerebrum vil vanlegvis fjerne alt den ikkje kjenner til, for å kunne holde OU-en ryddig.
  • Ein ledig Member Server i AD-domenet som Cerebrum må få tilgang til.
  • Tilgang til sertifikatgenerering i domenet - ein server i domenet treng å vere satt opp med rolla AD Certificate Service.

Det som i grove trekk trengs å gjerast frå Windows-sida:

  • Cerebrum treng to brukarar, ein lokal brukar for pålogging på Member Server, og ein domenebrukar med rettigheter til å administrere enkelt-OU i domenet. Domenebrukaren bør ha så få rettigheter som mulig for å likevel kunne utføre dei endringar som trengs i synken.
  • Eit klient-sertifikat må genererast og registrerast på påloggingsbrukaren.
  • WinRM må settast opp på Member Server, med det genererte sertifikatet.
  • Porten til WinRM på Member Server må vere open for tilkoblingar frå Cerebrum sitt produksjonsmiljø. Ta kontakt for å vite om kva som er gjeldande IP-adresser.

2   Klargjering av domenet

2.1   Globale innstillingar

Innstillingar som må settast for heile domenet eller alle OU som Cerebrum skal administrere:

  • Då passordkrav styrast av Cerebrum bør du endre sikkerhetsinnstillingar for passord i AD for å unngå problem med integrasjonen. I GPO, sett:

    • Enforce password history: 0 passord
    • Maximum password age: 0 dagar
    • Minimum password age: 0 dagar
    • Minimum password length: 0 teikn - kan eventuelt settast til eit høgare tal, men må ikkje overstige det som er satt i Cerebrum.

  • Deaktiver "Password must meet complexity requirements", sidan krav til passord vert utført i Cerebrum. Om dette ikkje settast vil passordbytter kunne feile, då Cerebrum kan ha andre krav enn AD til passordkompleksitet.

    Dette kan du endre i: Computer Configuration -> Windows Settings Security Settings -> Account Policy -> Password Policy -> Password must meet complexity requirements - settast til Disabled.

  • Skjul muligheten for passordskifte i AD ved å fjerne "Change Password" frå relevante brukarmenyar. Dette for å unngå mismatch mellom AD og andre tenester, som Feide.

    Dette kan du gjere i: User Configuration -> Administrative Template -> System -> Ctrl+Alt+Del Options -> Remove Change Password - settast til Enabled.

2.2   OU

Opprett og klargjer alle OU som Cerebrum skal administrere.

Vanleg praksis i bruk av OU for Cerebrum:

  • Ein samle-OU, til dømes OU=Cerebrum på rotnivå. Denne må Cerebrum få rettigheter til å administrere (sjå lenger ned).
  • Ein under-OU for brukarar, OU=Users,OU=Cerebrum.
  • Ein under-OU for grupper, OU=Groups,OU=Cerebrum.
  • Dersom sletta/avvikla brukarar skal flyttast til ein eigen OU treng vi OU=Deleted Users,OU=Cerebrum. Dette er valfritt, Cerebrum kan godt ha deaktiverte brukarar i samme OU som aktive.
  • Andre behov eller objekttypar kan føre til fleire under-OU.

Nokre retningslinjer for OU som Cerebrum skal administrere:

  • Ikkje flytt objekt som Cerebrum skal administrere ut av Cerebrum sine OU. Dette vil føre til at objektet vert flytta tilbake, eller at det vert feilmeldt og skaper støy. Dersom eit objekt ikkje lenger skal vedlikeholdast av Cerebrum må det først deaktiverast eller fjernast i Cerebrum.
  • Ikkje legg til objekt i OU som Cerebrum skal administrere. Slike objekt kan bli flytta, sletta eller feilmeldt og vil skape støy. Skal nye objekt inn i slike OU er riktig prosedyre å legge dei til i Cerebrum og la synkroniseringa opprette dei.

Det forventast at OU som Cerebrum skal administrere er rydda opp i, då Cerebrum vil fjerne dei objekta som den ikkje kjenner til. Det er to måtar å rydde i enhetane:

  1. Dersom ein er sikker på at OU-et ikkje inneheld nokon andre grupper og brukarar enn dei som allereie eksisterer i Cerebrum, kan desse bli ståande. Til dømes kan den gamle AD-synken sjå til at OU-et er som det skal, før vi starter den nye synken. Dette gjer at brukarar beheld sin SID og då også sine rettigheter.
  2. Slett, flytt eller deaktiver alle objekt som ligg i OU-et. Cerebrum vil då opprette alle grupper og brukarar som den vil, men den veit då ikkje om brukarar som ligg andre stader. AD-synken vil då klage på at den ikkje får oppretta AD-objekt, som skaper ekstraarbeid.
    • Merk at om AD ikkje har blitt oppdatert av Cerebrum tidlegare må alle brukarar som skal inn i Cerebrum få satt eit nytt passord. Dette kjem av at vi ikkje lagrer klartekstpassord til brukarar, og AD krever at vi sender over klartekstpassordet.
    • Cerebrum kan migrere eksisterande informasjon.

2.3   Migrering av eksisterande data i AD

Dette gjeld for instansar der AD ikkje har blitt synkronisert av Cerebrum tidlegare.

Dersom instansen ønsker å beholde brukarnamna som dei allereie har hatt i AD ved overgang til Cerebrum, må vi legge inn informasjonen om desse i Cerebrum. Det vi treng av migreringsdata:

  • Brukarnamn.
  • Personen som brukarnamnet tilhøyrer. Identifisert med studentnummer, ansattnummer eller eventuelt fødselsnummer. Merk at personen må eksistere i SAP, FS eller andre autoritative kjeldesystem for at vi skal kunne migrere personen og tilhøyrande brukarar.
  • Attributtar til brukaren, dersom desse skal beholdast. Merk at informasjon som telefonnummer og adresser vanlegvis hentast frå SAP, FS eller andre system, så det treng vi ikkje å hente frå AD.
  • Gruppetilgangar, dersom det er ønskeleg å beholde. Alternativt kan dette settast opp i ettertid av instansen sjølv gjennom administrasjonsverktøy som bofh.

Cerebrum drift kan opprette personar, brukarar og grupper i Cerebrum før vi starter AD-synkroniseringa. Brukarar med samme brukarnamn i AD vil då bli oppdaterte i staden for å bli oppretta på nytt.

Merk at alle brukarar må bytte passord i Cerebrum sjølv om dei vert migrerte. Cerebrum kan ikkje hente passord frå AD.

3   Oppsett av maskin

Cerebrum treng tilgang til ei maskin i domenet, ein Member Server, som vert springbrettet for Cerebrum for å snakke med AD-domenet. Cerebrum logger då på denne maskina gjennom WinRM og sender powershell-kommandoar for å gjere endringar i AD.

Cerebrum treng ikkje og ønsker ikkje direkte tilgang til domenekontrolleren, av sikkerhetsmessige årsaker. Integrasjonen vil likevel fungere om vi kommuniserer direkte med ein DC.

Krav til maskina:

  • Windows Server 2008 R2 eller seinare. Synken har blitt testa mot 2008R2 og 2012R2. Andre versjonar kan fungere, men dette er ikkje testa.

  • Powershell versjon 4 eller seinare.

  • Maskina må kunne snakke med og administrere AD gjennom ADWS. Dette er vanlegvis påslått.

  • Minne: Under test av domenet uio.no var 4GB meir enn godt nok.

  • Cerebrum treng ikkje remote desktop eller annan tilgang til denne maskina, berre tilgang via WinRM.

  • Maskina bør ikkje vere open tilgjengeleg for pålogging for vanlege brukarar.

  • Powershell-modulen ActiveDirectory må vere tilgjengeleg. Denne kan settast opp med å installere Remote Server Administration Tools (RSAT) feature (versjon for windows server 2008 og windows 7), (versjon for Windows Server 2012 og Windows 8).

    I Windows Server 2012 R2 kan RSAT installerast gjennom Server Manager -> Manage -> Add Roles and Features. Gå vidare til vinduet Features og velg Remote Server Administration Tools -> Role Administration Tools -> AD DS and AD LDS Tools -> Active Directory module for Windows Powershell.

    Test om modulen er installert riktig med å starte powershell og køyre:

    Import-Module ActiveDirectory

  • Dersom Cerebrum også skal oppdatere Exchange må Exchange Management Tools vere installert på Member Server. Det er versjonen av Exchange-kommandoane som er installert på maskina som bestemmer kva Exchange-versjon Cerebrum kan køyre mot.

  • Powershell må settast opp til å be om passord via kommandolinja og ikkje gjennom eigne popup-vindu. Køyr powershell-kommandoen:

    Set-ItemProperty 'HKLM:\SOFTWARE\Microsoft\PowerShell\1\ShellIds' ConsolePrompting $true

  • Dersom domenet ikkje har eit sertifikatregime, må ei maskin få tildelt rolla "Certification Authority". Dette kan settast opp for vår Member Server. Sjå meir info lenger nede.

4   Brukartilgang

Cerebrum treng to brukarar:

  1. Ein lokal brukar for autentisering gjennom WinRM mot Member Server.

    1. På Member Server, gå til Local Users and Groups og opprett ein brukar, til dømes med namnet cereauth. I Windows Server 2012 kan dette gjerast gjennom Computer Management.

      Brukaren kan ikkje vere ein domenebrukar, enn så lenge vi bruker sertifikat og Basic-autentisering.

      • Marker "Password never expires" ved oppretting, for å unngå uhell med å miste tilgangen.
      • Brukaren kan godt få lov til å bytte passord på seg sjølv.

    2. Gje brukaren tilgang til å logge på maskina gjennom WinRM. Dette kan gjerast ved å melde brukaren inn i Administrators på maskina, men vi ønsker å begrense rettighetene til brukaren.

      Dette er ikkje godt nok testa, men ein kan prøve å melde brukaren inn i den lokale gruppa WinRMRemoteWMIUsers__, til dømes med:

      net localgroup WinRMRemoteWMIUsers__ /add <domain>\<username>

    3. Gje Cerebrum drift passordet til brukaren på ein trygg måte. Ukryptert e-post er ikkje ein trygg måte.

  2. Ein domenebrukar som kan administrere Cerebrum sine OU i domenet.

    1. Opprett brukaren.

      • Legg den i eit OU utanfor dei Cerebrum skal administrere.
      • Passordet bør ikkje innehalde spesialteikn.
      • Brukaren må ikkje vere satt opp til å måtte automatisk fornye passordet, men den kan godt få lov til å bytte passord.

    2. Gje Cerebrum drift brukarnamn og passord på ein trygg måte. Ukryptert e-post er ikkje ein trygg måte.

    3. Gje brukaren tilgang til å administrere alle OU Cerebrum skal administrere. Dette gjerast vanlegvis ved å tildele rettighetane til ei gruppe og melde brukaren inn i denne gruppa - på den måten kan også andre få samme tilgangane som Cerebrum har, bl.a. for feilsøking.

      1. Opprett ei gruppe. Den kan til dømes heite cerebrum_administrators.
      2. Meld brukaren inn i gruppa.

      Rettighetsdelegeringa gjerast ulikt etter Windows Server 2012, så prosessen vidare vert ulik:

      • For Windows Server 2008:

        #. Gje gruppa rettigheter i *Active Directory Users and Computers* (denne kan leggast til som eit snap-in i mmc  dersom RSAT er installert, eller så kan du starte den med å køyre dsa.msc):

        1. Gå til View og velg Advanced Features. Dette er for å få opp fana Security.

        2. Høgreklikk på OU-et du skal gje Cerebrum rettigheter til. Velg Properties.

        3. Velg fana Security.

        4. Under "Group or user names" velger du Cerebrum-gruppa du har oppretta.

        5. Under neste boks må du velge Advanced og ikkje velge noko i boksen. Dette er fordi boksen berre gjeld for "This object only", medan vi ønsker å tildele rettighetene til under-objekt også.

        6. I vinduet for Advanced:

          • Applies to: This object and all descendand objects.

          • Permissions: Du kan velge å gje Cerebrum Full Control, men det er ikkje ønskeleg, sidan vi då også får tilgang til å ta over brukarar. Det er ei lang liste over rettigheter, og det vi treng:

            • List contents
            • Read all properties
            • Write all properties
            • Delete
            • Delete subtree
            • Read permissions
            • Modify permissions
            • All validated writes
            • Create account objects
            • Delete account objects
            • Create Computer objects - Nødvendig dersom Cerebrum skal administrere maskiner
            • Delete Computer objects - Nødvendig dersom Cerebrum skal administrere maskiner
            • Create Group objects
            • Delete Group objects
            • Create OrganizationalUnit objects
            • Delete OrganizationalUnit objects
            • Create Share Folder objects - Nødvendig dersom Cerebrum skal gjere noko med mapper.
            • Delete Share Folder objects - Nødvendig dersom Cerebrum skal gjere noko med mapper.
            • Create User objects
            • Delete User objects
            • Reset password

      • Properties:

        • Gjeld kva attributtar vi kan lese og skrive til. Velg dei attributta som dykk ønsker at Cerebrum skal administrere. Hugs å utvid rettighetene til Cerebrum ved utvida behov.

      • Dersom Exchange skal brukast må brukaren ha Exchange Recipient Administrator Role.

  3. For Windows Server 2012:

    1. Opne Active Directory Users and Computers.
    2. Høgreklikk på OU-et du vil at Cerebrum skal kunne administrere. Velg Delegate Control....
    3. Velg gruppa cerebrum_administrators for å tildele kontrollen.
    4. I Tasks to Delegate, velg Create a custom task to delegate.
    5. I Object type/scope kan du enten velge This folder, existing objects in this folder, and creation of new objects in this folder, eller så kan du begrense tilgangen til Cerebrum til spesifikke objekttypar.
    6. I Permissions, velg det som Cerebrum skal ha tilgang til.

4.1   Sertifikat

For å kommunisere med WinRM kryptert, må brukaren få tildelt eit sertifikat, og dette må settast opp for WinRM. Det er to måtar å administrere sertifikat i AD:

  • Enterprise: Domenet har då ein eller fleire Certificate Service Servers som brukast for å signere sertifikat. Ein set då dette opp som ein lokal Public Key Infrastructure (PKI). Dette kan gjerast så komplisert du berre vil, og vert ikkje beskreve i dette dokumentet.
  • Standalone:Den lokale maskina signerer då sine eigne sertifikat, og brukast berre lokalt. Dette er det enklaste. Det kan eksistere fleire standalone Certificate Services i eit domene, utan at dei har noko samanheng.

Denne dokumentasjonen beskriver berre korleis du kan sette opp sertifikat med Standalone, men om instansen har eit eige PKI-opplegg kan dette fint brukast i staden for. Det er ikkje nødvendig å måtte kjøpe inn sertifikat frå tredjepartar, vi kan godt bruke sjølvsignerte sertifikat frå instansen.

4.1.1   Sette opp Certificate Service Server

Først treng vi ei maskin som kan vere Certification Authority (CA) og signere sertifikata vi skal bruke. Dette kan godt vere maskina som Cerebrum skal snakke med, men det kan også vere ei anna maskin i domenet.

For å sette opp rolla Certificate Server:

  1. Meld maskina inn i riktig domene om den ikkje allereie er det. Du kan ikkje bytte domene etter at sertifikat-rolla er aktivert.
  2. På maskina som skal ha rolla, gå til Add Roles Wizard. Denne finn du under Server Manager, som kan leggast til som eit snap-in i mmc. I Windows Server 2012 gjerast dette i Dashboard -> Tools -> Add Roles and Features.
    1. Når du blir bedt om Role services, treng du berre å markere Certification Authority.
    2. Under Setup type velger du Standalone, med mindre instansen har ein PKI-struktur du vil bruke.
    3. Under CA type velger du Root CA, med mindre du vil bruke ein annan CA for å signere denne maskina sin nøkkel.
    4. Under Private Key velger du å generere ein ny privatnøkkel, med mindre maskina har vore reinstallert og du allereie har ein nøkkel du vil gjenbruke.
    5. Under Cryptography kan du velge etter instansen sin policy, men generelt anbefaler vi ei nøkkellengd på minst 2048 bits, og SHA512 som hashingsalgoritme.
      • Feltet "Allow administrator interaction when the private key is accessed by the CA" kan markerast for å kreve at administrator av maskina taster inn passordet sitt dersom privatnøkkelen skal brukast. Denne kan godt slåast på for at administratorar skal ha kontroll på nøkkelen, men det er opp til instansen sin policy. Vi kjem berre til å bruke privatnøkkelen når vi skal signere sertifikata som skal brukast, så administrator må ikkje taste inn passordet sitt så veldig mange ganger.
    6. Under CA Name kan Common Name vere default, altså domene og maskinnamn.
    7. Under Validity Period kan du godt auke lengda til over 10 år dersom nøkkelen berre skal brukast til WinRM og ingen andre kjem til å bruke den. Dette er opp til instansen. Før tida går ut må ny nøkkel genererast, og då også sertifikata som er i bruk.
    8. Under Certificate Database,velg default.
  3. Vent til installasjonen er ferdig. Det kan hende du må restarte maskina.

Då har maskina nøklar og rotsertifikat (CA) som kan brukast til å generere sertifikat.

4.1.2   Generer Certificate Request og eit signert sertifikat

For å få produsert eit signert sertifikatet for WinRM-tenaren må du først lage ein certificate request, som Certificate Service deretter kan produsere eit sertifikat ut av. Som eit alternativ kan Certificate Server settast opp med å køyre ein webservice som kan brukast for å generere sertifikat, men det vert ikkje dokumentert her.

For å generere eit certificate request må du lage ei .inf-fil. Dokumentasjon finn du hos Microsoft. Eit døme på formatet:

[NewRequest]
Subject="CN=MACHINE.EXAMPLE.COM"
Exportable=TRUE
KeySpec=1
KeyUsage=0xA0
KeyLength=4096
MachineKeySet=TRUE
ProviderType=12
RequestType=CMC
ProviderName="Microsoft RSA SChannel Cryptographic Provider"
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.1

Dersom du får feilmelding om at sertifikatet krever ein certificate template, kan du velge ein template for Machine.

For å få eit signert sertifikat:

  1. Lag ei .inf-fil med innstillingane til maskina.

  2. Generer ein certificate request med kommandoen certreq. Kommando:

    certreq.exe -new fil.inf request.txt

    Fila request.txt inneheld då ein certificate request. Du kan sjå på denne med kommandoen: certutil.exe -dump request.txt.

  3. Importer request-fila inn hos CA for signering. Dette kan gjerast gjennom webgrensesnittet på maskina som er CA (HTTPS://<MyDomainCertificateServer>/certsrv), men om du ikkje har, eller vil ha det, installert gjer du det gjennom Certification Authority:

    1. I Certification Authority: Høgreklikk på namnet på CA'en -> All Tasks -> Submit new request. Velg request.txt. Den vil då legge seg inn under "Pending Requests". Obs: Sertifikatet må ikkje ha "All operations", men berre vere for "Server Authentication".
    2. Under Pending Requests, høgreklikk på fila du vil legge til (request.txt). Velg All Tasks -> Issue. Den vil då legge seg under "Issued Certificates", og er då signert.

  4. Kopier sertifikatet over til maskina som Cerebrum skal snakke med. Sjå lenger ned for korleis du aktivere sertifikatet i WinRM.

4.1.3   Overlever CA-sertifikat til Cerebrum

For at Cerebrum skal kunne autentisere Windows-serveren, treng den tilgang til CA-sertifikatet som gav tilgangen, på riktig format for Linux (OpenSSL).

For å kunne hente ut CA-sertifikatet frå AD:

  1. Start Certificate Authority.
  2. Høgreklikk på CA-sertifikatet og velg "Open".
  3. Velg Copy to file og eksporter sertifikatet til ei fil ein passande stad.
  4. Ikkje legg ved privatnøkkelen til sertifikatet!
  5. Under format, velg: Base64-encoded certificate (.CER). Du treng ikkje legge ved andre sertifikat dersom CA er sjølvsignert.
  6. Importer sertifikatet på maskina som skal kommunisere med Cerebrum:
    1. Dersom CA ikkje er på samme maskin som Member Server som skal brukast for kommunikasjonen med Cerebrum, må du kopiere sertifikatet over på eit eller anna vis. Heimeområde, minnepinne eller noko anna. Merk at fila inneheld den private nøkkelen, så fila må ikkje delast ut på til dømes fellesdiskar!
    2. Gå til snap-in Certificate (lokalt for maskina). Høgreklikk på Personal -> All Tasks -> Import. Velg Local machine og finn fila du vil importere.
    3. Sertifikatet skal då vere klart til bruk for WinRM.

Merk: Om du ikkje får satt opp WinRM grunna ei feilmelding om at sertifikatet ikkje kan brukast eller er ugyldig: I Certificate (local machine):Høgreklikk på sertifikatet, velg Edit properties, og fjern alle properties bortsett frå Server Authentication.. Prøv deretter på nytt.

5   Sette opp WinRM

Sjå Installation and Configuration for Windows Remote Management for generell konfigurasjon av WinRM. Artikkelen Configuring WINRM for HTTPS kan også vere behjelpeleg. WinRM er allereie installert på nyare OS, så den treng som oftast berre å settast opp.

Krav til maskina:

  • Windows Remote Manager (WinRM) 2.0 eller seinare. Synken er testa mot versjon 2.0 og 3.0.
  • .NET Framework, versjon 3.5.1, 4.5 eller seinare.

For å sette opp WinRM for å kunne brukast av Cerebrum:

  1. Bruk Local Group Policy for å stille inn autentisering og tilkobling.
  2. Bruk winrm-kommandoen for å stille inn sertifikat, brannmur og alt anna.

5.1   Konfigurasjon med Local Group Policy

Nokre innstillingar må først settast opp gjennom *Local Group Pollicy*.

  1. Opne Local group policy editor, også kalla Edit group policy. Start det gjennom cmd ved å køyre "gpedit".

  2. Under Computer configuration -> Administrative templates -> Windows components -> Windows Remote Management (WinRM) -> WinRM Service:

    • Allow automatic configuration of listeners: Sett til Enabled. Legg til Cerebrum sine IP-adresser, så WinRM lytter til desse. Dersom instansen heller bruker brannmurar eller aksesslister for slikt, kan ein heller sette "*" her. Det viktigaste er at ein ikkje opner opp for oppkoblingar frå heile omverda. Denne innstillinga ser ut til å ha forsvunne i Windows 2012 og må då settast opp med winrm-kommandoen.
    • Allow Basic authentication: Sett til Enabled.
    • Allow unencrypted traffic: Skal vere Disabled. Kan settast til Enabled, men berre* for testmiljø som bruker fiktive test-data og test-domenet ikkje er satt opp med sertifikat endå.
    • Allow remote server management through WinRM: Sett til Enabled. Denne er ikkje tilgjengelig i eldre versjonar enn Windows 2012.

  3. Under Computer configuration -> Administrative templates -> Windows components -> Windows Remote Shell:

    • Allow Remote Shell Access: Sett til Enabled.

    • Specify idle Timeout: Sett til Enabled. IdleTimeout bør helst endrast til minst 10800000 ms (3 timar). Dette kjem av at fullsynkar kan ta lang tid om alle objekt må oppdaterast, typisk ved migrering.

      Obs: Ikkje sett denne til lågare enn 15 minuttar, då det vil gjere at Cerebrum ikkje får nok tid til å hente ut all informasjonen frå AD, så fullsynken får aldri starta.

      Merk at synkar som feiler eller vert forhindra i å fullføre, vil bli hengande og ta opp plass fram til timeout slår inn. Verdigen bør difor ikkje settast for høgt, sidan det kan hindre nye tilkoblingar/sesjonar.

    • MaxConcurrentUsers: Sett til Enabled, auk verdien til 1000 eller meir, avhengig av om andre også skal koble seg til maskina.

    • Specify maximum amount of memory in MB per Shell: Sett til Enabled, auk verdien til minst 1024 MB. Fullsynken hentar ut alle relevante AD-objekt i ein jafs, som krever ein del minne.

    • Specify maximum number of processes per Shell: Sett til Enabled, auk verdien til 1000, evt. meir. Kvar endring Cerebrum utfører reknast som ein "prosess", så når synken når begrensinga må den starte ein ny sesjon.

    • Specify maximum number of remote shells per user: Sett til Enabled, sett MaxShellsPerUser til 1000 eller meir. Dette er for å la fleire synkroniseringar kunne køyre samtidig. Dersom også andre skal bruke maskina kan det vere behov for å sette verdien lågare, det er opp til dei som drifter windows-maskina.

      Dersom ein synk skulle krasje, utan å få lukke det eksisterande shellet sitt, vil det då henge og ta opp plassen fram til idle timeout. Dersom maks antal shell er satt for låg, vil synken kunne få problem ved at Windows nekter den å opprette nye shell, og vi får ikkje synkronisert med AD i ein periode.

  4. Dobbelsjekk at endringane er utført med: winrm get winrm/config. Det kan hende du ikkje får køyrd denne med domenebrukaren din, men må bruke ein lokal brukar, til dømes cereauth:

    PS > winrm get winrm/config [-a:Basic -u:cereauth]
Enter the password for 'cereauth' to connect to '': xxxxxxxxxxxx
...
Service:
  ...
  AllowUnencrypted = false [Source="GPO"]
  Auth:
    Basic = true [Source="GPO"]
...
Winrs:
  AllowRemoteShellAccess = true [Source="GPO"]
...

Merk at Policy-innstillingar overstyrer kva som blir satt med winrm.

5.2   Konfigurasjon med winrm (cmd)

Kommandoen winrm kan konfigurere både klient og winrm-serveren på maskina ein køyrer kommandoen frå. Sjå winrm help config for meir informasjon om korleis innstillingane kan utførast. Merk at dersom denne kommandoen feiler, kan du heller bruke kommandoane Get-Item, Get-ChildItem, Set-Item, New-Item og Clear-Item.

Obs: Køyr `winrm` gjennom `cmd.exe` og ikkje gjennom `powershell.exe`, då visse parameter til kommandoen vert tolka av powershell og må difor escapast for å kunne køyrast.

Køyr først:

winrm quickconfig -transport:https

Dette set opp standardinnstillingar og opner opp brannmuren.

Når dette er gjort, skal WinRM vere ferdig tilgjengeleg på URL'en: https://HOSTNAME:5986/wsman.

Nokre settingar som kan vere interessante å endre på:

  • winrm/config/service/IPv4Filter og IPv6Filter kan endrast på for å filtrere ut andre hostar. Dette er opp til instansen sin policy, det er ikkje sikkert dette er nødvendig om det er brannmurar utanfor som set slike begrensingar.

5.2.1   Sette opp listener

Sjå til at du har ein listener for HTTPS, og om du er i produksjon, ikkje for HTTP:

C:\> winrm enumerate winrm/config/listener
Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 129.240.3.5, ::1, 2002:172e0:110:10::b359, fe80::100:7f:fffe%15, fe80::200:5efe:129.240.3.5%13

Listener
    Address = *
    Transport = HTTPS
    Port = 5986
    Hostname = winrm.example.com
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint = E161D65A279EFA3CE18BFEFAA3098EB010CEB17C14E43
    ListeningOn = 127.0.0.1, 129.240.3.5, ::1, 2002:172e0:110:10::b359, fe80::100:7f:fffe%15, fe80::200:5efe:129.240.3.5%13

For å legge til for HTTPS:

C:\> winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="FQDN";CertificateThumbprint="THUMBPRINT"}
ResourceCreated
    Address = http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous
    ReferenceParameters
        ResourceURI = http://schemas.microsoft.com/wbem/wsman/1/config/listener
        SelectorSet
            Selector: Address = *, Transport = HTTPS

For å fjerne listeners som ikkje skal vere der:

C:\> winrm delete winrm/config/Listener?Address=*+Transport=HTTPS

5.2.2   Alternativ: Set- og Get-Item gjennom powershell

Alternativt, om det er ønskeleg å bruke powershell, kan kommandoen Set-Item brukast.

Døme på å hente ut konfigurasjon:

PS \> Get-Childitem WSMAN:\localhost\service

   WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Service

Type            Name                           SourceOfValue   Value
----            ----                           -------------   -----
System.String   RootSDDL                                       O:NSG:BAD:P(A...
System.String   MaxConcurrentOperations                        4294967295
System.String   MaxConcurrentOperationsPerUser                 1500
System.String   EnumerationTimeoutms                           240000
System.String   MaxConnections                                 1000
System.String   MaxPacketRetrievalTimeSeconds                  120
System.String   AllowUnencrypted               GPO             false
Container       Auth
Container       DefaultPorts
System.String   IPv4Filter                                     *
System.String   IPv6Filter                                     *
System.String   EnableCompatibilityHttpList...                 false
System.String   EnableCompatibilityHttpsLis...                 false
System.String   CertificateThumbprint                          d0 61 d6 4a 2...
System.String   AllowRemoteAccess                              true

PS \> get-childitem WSMAN:\localhost\listener

   WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Listener

Type            Keys                                Name
----            ----                                ----
Container       {Address=*, Transport=HTTP}         Listener_809701527
Container       {Address=*, Transport=HTTPS}        Listener_1353925758

PS \> get-childitem WSMAN:\localhost\listener\Listener_1353925758

   WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Listener\Listener_1353925758

Type            Name                           SourceOfValue   Value
----            ----                           -------------   -----
System.String   Address                                        *
System.String   Transport                                      HTTPS
System.String   Port                                           5986
System.String   Hostname                                       winrm.exampl...
System.String   Enabled                                        true
System.String   URLPrefix                                      wsman
System.String   CertificateThumbprint                          E162D6422F9EF...
System.String   ListeningOn_1201550598                         127.0.0.1
System.String   ListeningOn_2092402225                         129.241.12.34
System.String   ListeningOn_1508953035                         ::1
System.String   ListeningOn_30010885                           2001:700:110:...
System.String   ListeningOn_936177975                          2001:700:110:...
System.String   ListeningOn_1575489928                         fe80::100:7f:...
System.String   ListeningOn_639509956                          fe80::200:5ef...
System.String   ListeningOn_1050627339                         fe80::f054:1e...

PS \> Set-Item WSMAN:\LocalHost\Client\Auth\Basic -Value $false

Ein skal til slutt sitte att med ein konfigurasjon som liknar omtrent på:

PS /> winrm get winrm/config
Config
    MaxEnvelopeSizekb = 500
    MaxTimeoutms = 60000
    MaxBatchItems = 32000
    MaxProviderRequests = 4294967295
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        Auth
            Basic = true
            Digest = true
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        TrustedHosts
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
        MaxConcurrentOperations = 4294967295
        MaxConcurrentOperationsPerUser = 1500
        EnumerationTimeoutms = 240000
        MaxConnections = 1000
        MaxPacketRetrievalTimeSeconds = 120
        AllowUnencrypted = false [Source="GPO"]
        Auth
            Basic = true [Source="GPO"]
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
            CbtHardeningLevel = Relaxed
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        IPv4Filter = *
        IPv6Filter = *
        EnableCompatibilityHttpListener = false
        EnableCompatibilityHttpsListener = false
        CertificateThumbprint = d0 61 d6 4a 27 9f fa 3c  e3 8b f6 fa a3 39 8e b10e b1 7c 06
        AllowRemoteAccess = true
    Winrs
        AllowRemoteShellAccess = true [Source="GPO"]
        IdleTimeout = 90000000 [Source="GPO"]
        MaxConcurrentUsers = 100 [Source="GPO"]
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 100 [Source="GPO"]
        MaxMemoryPerShellMB = 1024 [Source="GPO"]
        MaxShellsPerUser = 100 [Source="GPO"]

6   Brannmur og portar

Eventuelle eksterne brannmurar og aksesslister må opnast opp. Det som trengs av tilgangar:

  • Tilgang til WinRM frå Cerebrum sitt produksjonsmiljø til springbrettmaskina. Standard port for dette er 5986, og det er berre nødvendig med TCP.
  • Tilgang til ADWS frå springbrettmaskina (Member Server) til domenekontrolleren. Standard port for dette er 9389. Dette er mest sannsynleg allereie opna for i eit AD-miljø, då dette brukast for å synkronisere alle maskiner med AD-info.
  • Obs: Port 5985 er for ukryptert kommunikasjon og skal vere sperra ned i produksjon!

Cerebrum sitt produksjonsmiljø køyrer på maskinene:

  • cere-prod01.uio.no
  • cere-prod02.uio.no
  • cere-prod03.uio.no

Kvar instans har sin eigen host, på formatet:

  • cerebrum-<instans>.uio.no (til dømes cerebrum-uio.uio.no og cerebrum-nmh.uio.no)

7   Logging/auditing

Det er opp til instansen sjølv å sette opp så mykje overvåking av tenesta som ønskeleg. Cerebrum logger det som trengs for å kunne feilsøke frå vår side. Cerebrum logger ikkje kva endringar som er gjort i AD-domenet av andre, eller kva som er status i AD når vi oppdaterer.

For å sjekke loggen ved feilsøking:

  1. Opne Event Viewer.
  2. Gå til Applications and Services logs -> Microsoft -> Windows -> Windows Remote Management.

8   Oppsett av GnuPG på Windows-server

Det er ønskelig å kryptere brukerpassordene før de leveres til AD siden Cerebrum ikke har fått muligheten hittil til å levere passordhashene til AD.

Dette oppsettet er testet og installert på Windows Server 2012 R2.

  1. Logg på serveren med brukerkonto som har lokal administrator-tilgang.

  2. Last ned siste versjon av GPG4win: https://www.gpg4win.org/download.html

  3. Kjør installasjonen med standardvalg.

  4. Nøklene som senere genereres av GnuPG blir lokalisert her: c:\Users\[brukerkonto]\AppData\Roaming\gnupg. Hvis du vil bruke en annen katalog, legg til Environment-varibel GNUPGHOME til ønsket katalog. NB: Husk at brukerkontoen må ha lese- og skrivetilgang til ønsket katalog.

    Eksempel:

gnupg.png

  1. Nå skal nøkler genrereres, fra kommandolinje (cmd som administrator):

    • gpg --key-gen
    • Velg 1 RSA and RSA (default)
    • Velg 4096 bits som nøkkellengde
    • Velg ønsket eller ingen utløpsdato
    • Skriv inn navn, e-post-adresse og eventuelt kommentar
    • Trykk Ok når du blir bedt om passord. Privatnøkkelen skal ikke være passordbeskyttet.
    • Følg instruksjoner, nøklene blir generert

  2. Bekreft at nøkkelpar ble generert ved å skrive: gpg -k --fingerprint. Key fingerprint = .... viser den unike ID-en til nøkkelparet. Den offentlige nøkkelen skal vise 'trust' som [ultimate]. Eksempel på utskrift / resultat:

    pub   rsa4096 2016-02-10 [SC]
      5138 5560 3488 6EDA 5EFC  A38A C566 5D11 3736 D4B8
uid           [ultimate] Cerebrum (Nøkkelpar for AD-kryptering) <cerebrum-uio-drift@usit.uio.no>
sub   rsa4096 2016-02-10

  3. Eksporter deretter den offentlige nøkkelen ved å skrive: gpg --export -a -o filnavn.pub ID-i-en-streng-uten-mellomrom (eksempel gpg --export -a -o cerebrum.pub 5138556034886EDA5EFCA38AC5665D113736D4B8)

  4. Send den offentlige nøkkelen til cerebrum-<instansforkortelsesnavn som uio, uia ... f.eks.>@usit.uio.no

  5. Fingerprint bør verifiseres over telefon

Av jokim
Publisert 28. okt. 2016 07:43
Del på e-post