Single Sign On pro Azure AD Connect

Previously, it was necessary to provide Single Sign On to use ADFS, which were published by the Web Application Proxy server. Today we look at this news, which was released in Preview in December 2016 and brings great savings in terms of infrastructure built OnPremise. Allows use of Single Sign On (hereinafter SSO) without having to install Active Directory Federation Service (ADFS also) and Web Application Proxy ADFS as a proxy (hereinafter also WAP).

Abychom mohli provést toto nastavení, je nutné upgrade Azure AD Connect služby minimálně na verzi 1.1.370.0 v rámci, které byla tato funkcionalita umožněna (k dnešnímu dni už existuje verze 1.1.380.0 z prosince 2016..

Tento upgrade, jak píše Microsoft, není dostupný pro automatický upgrade vašeho Azure AD Connect a proto v případě, že chcete využívat této funkcionality, je nutné provést update služby ručně pomocí In-Place update Azure AD Connect.

Nejprve je nutné tedy stáhnout požadovaný update ze stránek společnosti Microsoft. Bohužel Microsoft uvolňuje vždy poslední build a tak je potřeba se podívat zda tento build chceme a zda nám přináší to co potřebujeme. V rámci FAQ Microsoftu existuje internetová stránka s release History pro Azure AD Connect: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-version-history , ve které najdeme vždy novinky a další věci co nám, který build přináší.

Tento návod nedoporučuji zákazníkům, kteří se ve službě Azure AD Connect nevyznají a neví jakým způsobem provádět troubleshoting Azure AD Connect, jelikož se jedná o klíčovou službu třeba pro Office365 může být vhodné zvolit si správného partnera, který vám upgrade provede a bude následně schopen velmi rychle najít řešení v případě vzniklého problému. Posledním doporučením je mít platnou zálohu nastavení Azure AD Connect služby. Takže můžeme začít. Nejprve tedy stáhneme Azure AD Connect ze stránek společnosti Microsoft, přičemž se musíme podívat, zda je zde uvedena požadovaná verze Azure AD Connect služby: https://www.microsoft.com/en-us/download/details.aspx?id=47594

Poté spustíme stažený MSI balíček, který nám nabídne provedení upgrade na serveru a informuje nás, že služba po dobu upgrade nebude dostupná, dokud nebude upgrade proveden.

Jakmile je upgrade hotov je nutno provést kontrolu služeb a zkontrolovat ve službách zda se provedlo jejich automatické spuštění. Následně se pak přihlásit do aplikace „Synchronization Service“ a provést kontrolu pomocí položky „About“ zda je služba upgradována na požadovanou verzi a zda nám funguje synchronizace.

Nyní jsme tedy provedli instalaci nové verze Azure AD Connect a určitě chceme zapnout funkcionalitu Azure AD Connect SSO. Abychom mohli toto udělat je nutno zajistit, aby doména, pro kterou bude SSO platné měla v Azure AD nastavenu hodnotu Managed místo Federated, pokud jsme používali ADFS a WAP, pokud ne tak výchozí hodnota každé domény je Managed. Přepnutí zpět do stavu Managed můžeme provést jednoduchým powershell příkazem po přihlášení do Online Služeb z powershellu.

Tento příkaz provede změnu nastavení: Set-MsolDomainAuthentication -DomainName {domain} –Authentication Managed

Je nutno počítat s tím, že daná změna nějakou dobu trvá a může to být až 120 minut než se doména přepne zpět z vašeho ADFS a proto si nechte na provedení změny dostatečné časové okno. Také je velmi vhodné, aby uživatelé nic nepoznali, provést změnu Comapny Brand skrze https://portal.azure.com nebo https://manage.windowsazure.com a nastavili si potřebná loga a další hodnoty, jako odkazy na helpdesk případně nějaké popisky.

Nyní máme tedy přepnutu MSOL doménu na „ADFS servery“ v Azure AD a můžeme přejít k vlastnímu nastavení SSO. Toto nastavení se provádí z aplikace Azure AD Connect a to spuštěním aplikace „Azure AD Connect“, která je schopna provádět globální nastavení a zapínání funkcionalit, případně vám umožňuje přepnutí do Active nebo Staging modu.

Pokud máme spuštěnu aplikaci, můžeme zvolit položku „Configure“ a přejít k vlastnímu nastavení. Po jejím zvolení se nám ukáží možnosti služby Azure AD Connect (Additional Task). Měli bychom nejprve provést kontrolu, zda chceme využívat Password synchronization a nebo Pass-through autentizaci. A proto vybereme položku „Customize synchronization option“.

Proklikáme jednotlivé kroky, až se dostaneme k položce „Optional Feature“ a zde buď zapneme nebo vypneme položku Password Synchronization.

Tak a nyní je asi dobré si říct, proč Password Synchronization. Azure AD Connect SSO umožňuje využívat 3 typy autentizace a to Password hash synchronization a nebo Pass-through authentication nebo Federaci skrze ADFS (tu jsme využívali dříve a dneska se jí nebudeme zabývat). Tudíž pokud bychom chtěli, aby Azure AD posílalo vždy dotaz na heslo do naší infrastruktury a hesla nebyla cachovaná v Azure AD musíme použít Pass-through authentication a tudíž vypnout Password Synchronization. Toto je určitě bezpečnější řešení, nicméně bez služby Azure AD Connect nebude nikdy fungovat přihlášení například do Office365, CRM Online, atd.. a pokud máte jen jeden server, pak bych doporučil spíše hesla synchronizovat.

Pokud tedy máme jen jeden server a chceme, aby byla služba méně závislá na naší infrastruktuře a výpadek služby neměl fatální dopad na služby jako Office365, pak ponecháme nebo zapneme Password synchronization v Azure AD Connect a využijeme tak služby Password hash synchronization.

Nyní tedy dokončíme nastavení. Máme provedeno nastavení pro synchronizaci hesel do Azure AD a musíme povolit novou funkcionalitu Azure AD Connect SSO, které se povoluje po spuštění aplikace „Azure AD Connect“, jen v Additional Task vybereme možnost „Change user Sign-In“, jak je uvedeno na obrázku níže.

Zde můžeme tedy provést změny nastavení a povolit nastavení „Pass-through authentication“ nebo ponechat nastavení na „Password Synchronization“, ale také je nutno níže zaškrtnout „Enable single sign on“. Poté co zaškrtneme toto volbu, budeme moci modifikovat nastavení pro SSO. Abychom, mohli celou konfiguraci dokončit, bude nutné přiřadit službě účet s právy Domain Admins. Microsoft pro Azure AD Connect a jeho instalaci uvádí, že byste měli mít účet s právy Enterprise Admins, aby mohla probíhat synchronizace. Pod tímto účtem běží služba Azure AD Connect v systému a jelikož musí být na úrovni forestů instalován Azure AD Connect server jen jednou, je nutné, aby daný účet měl přístup do všech domén ve forestu. Pro SSO vyžaduje však účet práva Domain Admins a to explicitně, nelze tedy říci, že Enterprise Admins je dostatečný, i když má vyšší oprávnění, než Domain Admins a proto tato práva musíte účtu nastavit explicitně. Takže přiřadíte účet do skupiny, nastavení v konfiguraci a je téměř hotovo.

Aby bylo na klientech možno využívat Kerberos a bylo umožněno SSO pro klienty je nutné provést ještě jedno nastavení v rámci klientského operačního systému a to nastavení v Trusted Site. Nastavení je možno provést ručně anebo pomocí GPO. Je určitě dobré toto nastavení udělat hned na začátku, abychom měli jistotu, že klienti mají toto nastavení natažené, a že nedojde k problému s přihlášením do služeb Office365. Služby Office365 s ADFS využívali nastavení Trusted Site také, aby bylo zajištěno SSO a proto stačí danou Group Policy pouze rozšířit o nové URL. Pokud ji však nemáte nastavenu vůbec, pak je vhodné použít tato nastavení pro klientské Trusted Site nastavení v internetovém prohlížeči.

V rámci Intranet Zone je nutno zajistit, aby existovali tyto stránky:

• https://autologon.microsoftazuread-sso.com>
• https://aadg.windows.net.nsatc.net
• - *.microsoftonline.com
• - *.sharepoint.com
• - *.outlook.com
• - *.lync.com

V rámci Trusted Site je nutno zajistit, aby existovali tyto stránky:

• https://*.outlook.com/
• https://*.sharepoint.com/
• https://*.microsoftonline.com/
• https://*.lync.com/

Tím je celé nastavení hotové a můžeme využívat na klientech SSO skrze Azure AD Connect. A jak to vlastně funguje?

Uživatel se pokusí přistoupit na nějakou Online službu integrovánu s Azure AD a to za předpokladu, že daná URL aplikace je umístěna v Trusted Site. Uživatel této službě předá své uživatelské jméno (userPrincipalName) a služba Azure AD zjistí, zda je pro danou doménu (domain sufix) povoleno jednotné přihlášení. Za předpokladu, že je přihlášení povoleno probíhá následující proces ověření uživatele:

• Azure AD vrací na klienta odpověď 401 v Kerberos tiketu
• Klient požádá interní Active Directory o vystavení Kerberos tiketu pro službu Azure AD
• Active Directory vyhledá účet počítače v doméně
• Pokud jej najde, pak vystaví Kerberos tiket, který je šifrovaný pomocí účtu počítače a obsahuje uživatelské jméno pro přístup do Azure AD
• Klient vezme tento Kerberos tiket a odešle jej do služby Azure AD
• Azure AD pomocí předem sdílného klíče rozšifruje tento tiket a buď povolí uživateli přístup k interním zdrojům, nebo si vyžádá další úroveň ověření, jako je například multifaktor

Pokud se ověření nepovede, je uživatel požádán o zadání hesla přístupu. Tato situace může nastat za předpokladu, že klientský počítač je sice členem domény, ale z nějakého důvodu se nemůže přihlásit k doménovému řadiči nebo není služba Azure AD Connect dostupná. Výpadek služby Azure AD Connect však neznamená nefunkčnost služby, ale pouze snížení komfortu uživatele.

Pamatujte, že je nutné vždy zajistit, aby:.

• Počítač byl členem domény
• Fungovala komunikace na Active Directory a byl viditelný alespoň jeden doménový řadič
• Měli jste nastaveny Trusted site na klientském PC

Dále je nutné pamatovat na to, že fungování těchto služeb je zajištěno jen u níže uvedených internetových prohlížečů a operačních systémů.

Závěrem

Tímto jsme se posunuli k větší nezávislosti na interní infrastruktuře a zajištění komfortu uživatelů pro přístup do Online služeb jako jsou například Office365. Dříve totiž výpadek ADFS nebo WAP znamenal nefunkčnost celé služby. Nyní však nové nastavení znamená pouze snížení komfortu uživatelů a tím i větší prostor na případný troubleshoting dané služby.