Skip Ribbon Commands
Skip to main content

Ondrej Sevecek's Blog

:

Engineering and troubleshooting by Directory Master!
Ondrej Sevecek's Blog > Posts > Zážitky z pole - single server ADFS 2.0 migrace na ADFS 3.0 farmu
leden 14
Zážitky z pole - single server ADFS 2.0 migrace na ADFS 3.0 farmu

Myslím, že je občas dobré podělit se s prakticky ověřeným výsledkem, zvláště když se jedná o ještě pořád poměrně novou technologii. Takže úspěšně jsem zmigroval jednoserverový AD FS 2.0 (Windows Server 2008 R2) na dvouserverovou NLB farmu s AD FS 3.0 (Windows Server 2012 R2) bez WAP (Web Application Proxy neboli ADFS Proxy) pro ověřování Office365 pro 20 tisíc uživatelů. Cílem je minimální výpadek, který jste schopni dostat do řádu cca 1 minuty.

Tak snad to někomu pomůže.

Zákazník nemá WAP, takže nerozlišíme klienty z internetu a z vnitřní sítě, ale to je zrovna tady požadavek zákazníka. Nemůžeme tím pádem bohužel také udělat extranet lockout, ale to už je prostě život :-) Kdo neví o co všechno se jedná, může přijít na můj kurz o ADFS :-)

Průběh akce do okamžiku, kdy už to budete muset přehodit na novou farmu:

  • zjistit jaké DNS jméno (A, nebo móžná CNAME) používá stávající ADFS 2.0. Budeme přecházet na NLB s Kerberos ověřením, takže budeme muset přejít za každou cenu na jeden A záznam.
  • zjistit login a heslo servisního účtu stávajícího ADFS 2.0, protože použijeme stejný. Stejný použijeme, protože nová farma se bude muset chvilku připravovat a přitom se musí počítat se stejným jménem (a tím pádem SPN - service principal name), jako u staré farmy.
  • nainstalovat na nové servery NLB a rozchodit ho při režimu No afinity. K tomu je vhodné rovnou si tam dát IIS, i když byste ho pro AD FS 3.0 už dneska přímo nepotřebovali, ale bude se nám hodit zaprvé na zkoušení NLB, ale hlavně na různé HTTP redirect na přihlašovací stránky apod. Můžete taky rovnou implementovat nějaký sledovací skript, který potom už jenom jednoduše přehodíte vůči ADFS URL.
  • vygenerovat nový, nebo přenést původní TLS/SSL server authentication certifikát z AD FS 2.0. Chceme veřejný certifikát, protože nemáme v tomto případě WAP a tím pádem bude Office365 čučet přímo na náš nový AD FS 3.0 server (ano, pokud chcete používat Outlook, tak za určitých situací se přímo Office365 připojuje k vám na vaše ADFS - což by nebylo potřeba, pokud byste používali pouze webový přístup přes prohlížeč - obecně passive client).
  • nainstalovat nejprve první a potom do nové farmy přidat i druhý AD FS 3.0 server. Použijeme stejné jméno jako původní AD FS 2.0. Použil jsem scénář bez plného SQL serveru, jen za pomoci nezávislých WID (Windows Internal Database) databází. Ověřeno, že to v AD nic nezničilo. SPN na účtu služby to nepokazilo a do kontejneru CN=ADFS,CN=Microsoft,CN=Program Data,DC=x to jenom přidává další unikátní identifikátory token-signing a token-encryption certifikátů.
  • staré token-signing a token-decryption certifikáty (self-signed) z původního ADFS 2.0 nepřenášíme, necháme vygenerované nové self-signed.
  • na DNS záznam zatím nesaháme a tudíž původní ADFS 2.0 stále běží a přidání nové farmy zatím nehraje žádnou roli.
  • na nové farmě můžeme tedy poladit některé věci, jako je třeba prodloužení životnosti self-signed token certifikátů pomocí Set-AdfsProperties -CertificateDuration a Update-AdfsCertificate -Urgent. Rád si také zkracuji ADFS replikaci uvnitř farmy, aby to jelo rychleji pomocí Set-ADFSSyncProperties -PollDuration.
  • na novou farmu můžete v klidu překlikat Relying Party Trust pro Office365. Ani teď to ještě pořád není v provozu a pořád běží původní ADFS 2.0. Upozorňuji, že jsem v tomto okamžiku ještě vůbec nesahal do Office365. Takže máme sice novou ADFS 3.0 farmu, ale Office 365 o ní prozatím vůbec neví.
  • můžete začít testovat ověrování a forms authentication tak, že si na několika vybraných klientech nastavíte novou IP adresu nové farmy do HOSTS souboru. Offíce 365 o nás pořád ještě neví, takže se nedostanete zaručeně dále, než k tomu, aby vás vaše ADFS přesměrovalo do Office365, kam se ale už nedostanete, protože Office365 o naší farmě pořád ještě neví.
  • pokud to neověřuje, zkontrolujte, jestli vám jede Kerberos S4U - musíte servisní účet toho ADFS dát do skupiny Windows Authorization Access Group. A pokud máte v pravidlech nějaké další AD atributy, musí servisní účet ADFS být schopen je číst přímo z AD DS LDAPu samozřejmě.
  • to ale nevadí, celé ověřování (login), formuláře i jejich grafické úpravy a odhlášení (sign-out) uvidíte a ověříte že to funguje, cookie jsou v pořádku a že to NLB balancuje a že je možné ho zhodit apod. Můžete si klidně rovnou upravit onload.js a ostatní věcí prováděné pomocí Set-AdfsWebTheme a Set-AdfsWebConfig. Protože dneska s AD FS 3.0 už nebudete modifikovat přímo zdrojové aspx soubory, ale musíte to konfigurovat pomocí PowerShell, nebo právě přes JavaScript getElementId() apod.
  • do IIS, které máte na ADFS 3.0 nainstalováno ručně navíc (nemusí tam být vůbec), můžete přidat libovolné HTTP redirect. Například z HTTP na HTTPS, přidat si tam HSTS a samozřejmě takové to zrychlovací přihlašovací URI, abyste z prohlížeče nechodil na dvakrát přes Office365 (něco jako https://adfs.gopas.cz/adfs/ls?wsignin1.0&wtrealm=https://portal.gopas.cz).
  • ani jsem nečekal, že by nemělo fungovat, ale přesto jsem ověřil, že NLB jede jak v unicast mode, tak v multicast mode režimu.

Teď už jste nachystaní na přeskok. Víme, že nová ADFS farma funguje až do okamžiku, kdy to ověřeného uživatele přesměruje do Office365 a ten ho odmítne. Odmítne ho proto, že nově generované tokeny jsou digitálně podepsané novým self-signed certifikátem, o kterém Office 365 nic neví. V tomto okamžiku už musíte udělat definitivní přehození.

  • nemusíte měnit v DNS IP adrese (zbytečně dlouhé TTL), stačí přehodit IP adresu mezi starou a novou AD FS farmou, takže i ta vlastně zůstane původní.
  • to podstatné ale musíte změnit v Office365. Musíte zaktualizovat token-signing certifikát. Použijete Azure AD PowerShell module.
Import-Module MSOnline
Get-Credential
Connect-MSOLService
Get-MSOLFederationProperty
Set-MsolADFSContext -Computer localhost -LogFile
Update-MSOLFederatedDomain

  • poslední krok, který nezapomeňte, je buď úplně vypnout starou ADFS 2.0 farmu, nebo na ní minimálně vypnout právě aktualizaci token-signing certifikátů. Míváte to tam zaregistrováno jako naplánovanou úlohu (task scheduler), která se na staré farmě spouští o půlnoci, tak aby vám to certifikáty zase po pár hodinách samo nezkazilo, jako mě :-)

Ověřil jsem, že přepnutí trvalo cca minutu a od toho okamžiku to zase fungovalo, takže vyhrožování, že aktualizace certifikátu v Azure se může protáhnout se nenaplnilo. Samozřejmě kdo ví, jestli to tak je vždycky. Zbytek funkčnosti je samozřejmě vhodné ověřit pomocí Microsoft Remote Connectivity Analyzer. A fičíme.

Comments

There are no comments for this post.

Add Comment

Title


Pole Title nemusíte vyplňovat, doplní se to samo na stejnou hodnotu jako je nadpis článku.

Author *


Pole Author nesmí být stejné jako pole Title! Mám to tu jako ochranu proti spamu. Roboti to nevyplní dobře :-)

Body *


Type number two as digit *


Semhle vyplňte číslici dvě. Předchozí antispemové pole nefunguje úplně dokonale, zdá se, že jsou i spamery, které pochopily, že je občas potřeba vyplnit autora :-)

Email


Emailová adresa, pokud na ni chcete ode mě dostat odpověď. Nikdo jiný než já vaši emailovou adresu neuvidí.

Attachments