Azure SSO

[YaYo86]

Hi all,

Ik probeer uit te vogelen hoe wij SSO geïmplementeerd kunnen krijgen voor onze AAD setup op kantoor. Azure joined laptops binnen onze organisatie hebben namelijk nog geen SSO naar portal.office.com. Nou heb ik uiteraard veel gelezen over dit topic en overal zie ik ADFS weer terugkomen om SSO op te zetten. Echter wil ik de omgeving zo simpel mogelijk houden. Is er een andere manier om SSO op te zetten zonder dat users een tweede keer hun credentials (of iig het popup scherm niet nog een keer krijgen) moeten invoeren op bijv portal.office.com?

[YaYo86]

Niemand een idee?

[Oogje]

Moet je de trein halen ofzo?

Als je echt SSO wilt zul je ADFS nodig hebben. Er is nog een mogelijkheid met AAD & password sync. Dan kunnen je users "remember password" aanvinken. Maar das een "smerige" oplossing imo.

[YaYo86]

Oogje schreef op maandag 12 december 2016 @ 13:56:
Moet je de trein halen ofzo?

Als je echt SSO wilt zul je ADFS nodig hebben. Er is nog een mogelijkheid met AAD & password sync. Dan kunnen je users "remember password" aanvinken. Maar das een "smerige" oplossing imo.

Ja klopt die moet ik halen

AAD en pw sync heb ik nu maar daar wil ik van af ivm dirty inderdaad. Dan wordt het tijd om me te gaan verdiepen in ADFS!

[ Voor 52% gewijzigd door YaYo86 op 12-12-2016 14:12 ]

[Question Mark]

YaYo86 schreef op maandag 12 december 2016 @ 14:12:
[...]

Ja klopt die moet ik halen

Ja dus? Dat is nog geen enkele reden om je niet aan de regels te houden... In het algemeen beleid staat duidelijk dat het nodeloos omhoog kicken van je topic binnen 24 uur niet op prijs gesteld wordt.

[Jazzy]

Wat is er dirty aan password hash syncs? Dit is een volledig supported oplossing en biedt een mooie balans tussen gebruiksvriendelijkheid en complexiteit.

Verder kun je nog eens naar Pass-Through Authentication kijken. Ietsjes complexer dan password hash sync maar iets minder complex dan ADFS. Zie https://blogs.technet.mic...-seamless-single-sign-on/

[CAPSLOCK2000]

Jazzy schreef op maandag 12 december 2016 @ 17:06:
Wat is er dirty aan password hash syncs? Dit is een volledig supported oplossing en biedt een mooie balans tussen gebruiksvriendelijkheid en complexiteit.

Daarmee geef je toch al je wachtwoorden aan een externe partij? Ze zijn weliswaar gehashed maar dat is niet echt een beveiliging waar je op kan vertrouwen. Zelfs als je wel op z'n hash vertrouwt dan is het conceptueel nog niet verstandig. De wachtwoordcontrole (vergelijk met de hash) wordt dan namelijk op de servers van de derde partij gedaan. Dat betekent dat het wachtwoord op een of andere manier unencrypted op die server moet komen. In de meeste SSO-opstellingen probeer je dat juist te vermijden, alle wachtwoorden (en alle wachtwoordcontroles) blijven lokaal. Je centrale SSO-server geeft aan of de gebruiker succesvol is ingelogd, niet met welk wachtwoord dat is gedaan.

Excuses als ik er helemaal naast zit, ik geen ADFS niet en weet niet wat een password hash sync in die context precies betekent, maar het klinkt niet goed.

[Jazzy]

Nee, de wachtwoorden worden niet onversleuteld verzonden, ook niet onversleuteld opgeslagen en je hoeft ook geen hashmechanisme te gebruiken dat omkeerbaar is. In dat opzicht is het niet vergelijkbaar met zo'n webshopje die je vergeten wachtwoord gewoon in plain-text op weet te rakelen en naar je toe mailt.

Hier staat het in algemene termen beschreven: https://docs.microsoft.co...-password-synchronization Hier een blog over een partij die met een sniffer op de lijn kijkt: https://www.cogmotive.com...-password-synchronisation En hier nog wat meer details over het hashen en de kraakbaarheid: http://www.kraftkennedy.c...o-azure-active-directory/

Als je dit niet acceptabel vindt om principiële redenen dan is het prima natuurlijk, maar bij het woord 'dirty' denk ik aan unsalted hashes in een MySQL databaseje die uiteindelijk gekraakt op Pastebin eindigen.

[ Voor 11% gewijzigd door Jazzy op 12-12-2016 20:09 ]

[Question Mark]

Password (hash) sync (eigenlijk het syncen van de hash van de passwordhash) is een methode om cross platform met dezelfde credentials aan te kunnen loggen. Het is echter nog geen SSO oplossing. Er zal nog steeds een gebruikersnaam wachtwoordcombinatie ingevoerd moeten worden.

Het enige alternatief is het implementeren van ADFS waar authenticatie on-premise plaatsvind. Er wordt bij de lokale ADFS omgeving een token opgehaald die vervolgens aan federated omgevingen getoond kan worden. Domainjoined werkplekken kunnen bij een juiste inrichting dan automatisch het token al ophalen waardoor het aanloggen voor de user gezien seamless gaat.

Nadeel is alleen de extra investering in (volgens best practice) 4 extra systemen. Twee ADFS proxy's in de DMZ, en twee ADFS servers in het interne lan. Vandaar dat MS voor kleinere omgevingen het syncen van password hashes geintroduceerd heeft. Voor sommige omgevingen is dit een prima oplossing.

[Trommelrem]

Password passthrough is nu toch in beta? Ik heb het in een lab omgeving draaien en het werkt eigenlijk best goed. Als er een verbinding is met je DC, dan heb je SSO. Ben je buiten je site en heb je geen verbinding met je DC of is je DC offline, dan kun je alsnog inloggen maar dan is het geen SSO.

[CAPSLOCK2000]

Hashes wel niet omkeerbaar maar ook niet onfeilbaar, er zijn in de loop der jaren verschillende technieken ontwikkeld om hashes aan te vallen (bv rainbowtables) en je weet nooit wat de toekomst brengt. Daarom alleen al heb ik liever niet dat anderen mijn wachtwoorden hebben.

Verder is het conceptueel mooier om je data maar op één lokatie te hebben staan in plaats van te moeten synchroniseren tussen verschillende partijen.

Ten slotte moet je bij een wachtwoord(hash) sync er op vertrouwen dat die andere partij de wachtwoorden netjes en veilig behandelt. Zelfs de beste partner maakt fouten. Ik heb liever één centrale plek om in te loggen die ik zelf controleer dan dat ik de inlogmethodes van verschillende externe partners en applicaties moet controleren of (jek) vertrouwen.

[Question Mark]

CAPSLOCK2000 schreef op dinsdag 13 december 2016 @ 01:08:
Ik heb liever één centrale plek om in te loggen die ik zelf controleer dan dat ik de inlogmethodes van verschillende externe partners en applicaties moet controleren of (jek) vertrouwen.

Ik ook, maar de investering in ADFS is voor kleine bedrijven veel te duur. Men gooit één SBS server de deur uit (sharepoint, mail en filestorage) en krijgt er vier voor terug voor ADFS. Dat krijg je niet verkocht

Dan is er of de keuze tussen gebruik maken van totaal verschillende credentials, of gebruik maken van passwordhash sync.

[Trommelrem]

CAPSLOCK2000 schreef op dinsdag 13 december 2016 @ 01:08:
Ten slotte moet je bij een wachtwoord(hash) sync er op vertrouwen dat die andere partij de wachtwoorden netjes en veilig behandelt. Zelfs de beste partner maakt fouten. Ik heb liever één centrale plek om in te loggen die ik zelf controleer dan dat ik de inlogmethodes van verschillende externe partners en applicaties moet controleren of (jek) vertrouwen.

In de praktijk staan deze hashes veiliger opgeslagen bij Microsoft dan op een lokale DC
Zeker bij de doelgroep van passwordsync (= MKB) waar fysieke security vaak een probleem is.

[ Voor 7% gewijzigd door Trommelrem op 13-12-2016 08:32 ]

[Jazzy]

CAPSLOCK2000 schreef op dinsdag 13 december 2016 @ 01:08:
Hashes wel niet omkeerbaar maar ook niet onfeilbaar, er zijn in de loop der jaren verschillende technieken ontwikkeld om hashes aan te vallen (bv rainbowtables) en je weet nooit wat de toekomst brengt. Daarom alleen al heb ik liever niet dat anderen mijn wachtwoorden hebben.

De versleutelde hashes van je wachtwoorden. Zoals ik al zei, je moet vooral doen waar jij je prettig bij voelt, maar ik kan wel een paar gaten in je redenering slaan. Om te beginnen is geen enkele oplossing onfeilbaar, wat je doet is streven naar het beste wat redelijkerwijs haalbaar is. De onomkeerbare dubbele versleuteling van de hashes is door de industrie breed geaccepteerd, waarom zou die voor jou dan niet veilig genoeg zijn? Ik neem aan dat je ook Kerberos gebruikt en legio andere protocollen en producten waar wel degelijk met regelmaat vulnerabilities voor gevonden worden.

Verder is het conceptueel mooier om je data maar op één lokatie te hebben staan in plaats van te moeten synchroniseren tussen verschillende partijen.

"Conceptueel mooi" is nogal subjectief. Verder sync je werkelijk alle relevante attributen van je objecten naar Azure AD omdat je anders van geen dienst gebruik kunt maken. Om nog maar te zwijgen waar de applicatiedata staat. "Een lokatie" voelt misschien fijn, maar heeft niets met veiligheid te maken.

Ten slotte moet je bij een wachtwoord(hash) sync er op vertrouwen dat die andere partij de wachtwoorden netjes en veilig behandelt. Zelfs de beste partner maakt fouten. Ik heb liever één centrale plek om in te loggen die ik zelf controleer dan dat ik de inlogmethodes van verschillende externe partners en applicaties moet controleren of (jek) vertrouwen.

Haha, morgen loopt iemand je pandje in en vertrekt met de server onder zijn armen. Weg data, weg gevoel van veiligheid. Je redenering klopt volledig, als jij daadwerkelijk beter in staat bent om de beveiliging te verzorgen dan Microsoft.

Ten slotte, nog even over dat vertrouwen. Je kiest vervolgens voor ADFS en implementeert de 4 servers en load balancers en legt de trust met de Microsoft Federation Gateway. En dan zeg je tegen Microsoft dat ze logins mogen toestaan als de gebruiker een token heeft gekregen. Hierbij vertrouw je op ADFS (door Microsoft gebouwd) op Windows (door Microsoft gebouwd), de Federation Gateway (door Micrsoft gebouwd en gehost) om toegang te geven tot diensten die Microsoft bouwde en host. Omdat je de externe partij niet voldoende vertrouwt. Ja ja...

[ Voor 11% gewijzigd door Jazzy op 13-12-2016 08:51 ]

[Vincent17]

Die Azure joined laptops. Als dat Windows 10 Azure AD joined machines zijn, zouden deze al een SSO ervaring moeten hebben naar Office365/Azure workloads.

[CAPSLOCK2000]

Jazzy schreef op dinsdag 13 december 2016 @ 08:46:
De versleutelde hashes van je wachtwoorden. Zoals ik al zei, je moet vooral doen waar jij je prettig bij voelt, maar ik kan wel een paar gaten in je redenering slaan. Om te beginnen is geen enkele oplossing onfeilbaar, wat je doet is streven naar het beste wat redelijkerwijs haalbaar is. De onomkeerbare dubbele versleuteling van de hashes is door de industrie breed geaccepteerd, waarom zou die voor jou dan niet veilig genoeg zijn? Ik neem aan dat je ook Kerberos gebruikt en legio andere protocollen en producten waar wel degelijk met regelmaat vulnerabilities voor gevonden worden.

Laat ik het zo zeggen, als je gehashte wachtwoord file lekt dan moet je een datalek melden, als ze echt versleuteld zijn hoeft dat niet. Die hashes zijn geaccepteerd om wachtwoorden in op te slaan, niet om ze vervoeren.

Microsoft kun je misschien nog vertrouwen maar hoeveel andere externe partijen die zo'n password sync willen doen hebben hun zaakjes net zo goed op orde? Daarbij ga ik liever uit van "zeker weten" dan van "vertrouwen".

Ik snap best wel dat het voor sommige bedrijven te duur is maar dat is een beetje de ziekte van de IT, alles is te duur dus overal worden zaken maar half gedaan. Dat maakt het nog geen goed model.

[Trommelrem]

CAPSLOCK2000 schreef op dinsdag 13 december 2016 @ 09:42:
[...]
Ik snap best wel dat het voor sommige bedrijven te duur is maar dat is een beetje de ziekte van de IT, alles is te duur dus overal worden zaken maar half gedaan. Dat maakt het nog geen goed model.

Juist wel, omdat het bij Microsoft veiliger wordt opgeslagen dan lokaal. Daarom is het model juist goed.
Als je het zelf niet goed genoeg vindt, dan ga je toch voor ADFS? Maar dan moet je ook de benodigde waakhonden aanschaffen, trainen en voeren.

[Question Mark]

CAPSLOCK2000 schreef op dinsdag 13 december 2016 @ 09:42:
[...]
Die hashes zijn geaccepteerd om wachtwoorden in op te slaan, niet om ze vervoeren.

En daarom worden ze ook niet gebruikt voor vervoer. Voordat de hashes getransporteerd worden naar MS vindt er nog een hash/encryptieslag plaats.

To synchronize your password, Azure AD Connect sync extracts your password hash from the on-premises Active Directory. Extra security processing is applied to the password hash before it is synchronized to the Azure Active Directory

[Jazzy]

CAPSLOCK2000 schreef op dinsdag 13 december 2016 @ 09:42:
[...]

Laat ik het zo zeggen, als je gehashte wachtwoord file lekt dan moet je een datalek melden, als ze echt versleuteld zijn hoeft dat niet. Die hashes zijn geaccepteerd om wachtwoorden in op te slaan, niet om ze vervoeren.

Wat is dan het verschil tussen echt versleuteld en een hash? Volgens mij heb je dat derde artikel niet gelezen die ik eerder gaf. De wachtwoorden staan al niet in plain-text op je domain controller, we hebben het alleen maar over een hash om mee te beginnen. Die hash wordt vervolgens met MD5 en salt versleuteld en op deze manier naar de on-premises AADSync server verplaatst. Daar wordt hij opnieuw verleuteld met SHA256 en over een SSL encrypted tunnel naar Microsoft gestuurd. Microsoft heeft dan dus een hash van een hash van een wachtwoord.

Je moet nooit ergens zo maar op vertrouwen maar het zelf goed onderzoeken en dan je oordeel vormen.

[YaYo86]

Vincent17 schreef op dinsdag 13 december 2016 @ 08:51:
Die Azure joined laptops. Als dat Windows 10 Azure AD joined machines zijn, zouden deze al een SSO ervaring moeten hebben naar Office365/Azure workloads.

Dat is dus std niet het geval, credentials moeten 2x worden opgegeven.

[Jazzy]

Welke browser gebruik je? En er wordt ingelogd in Windows 10 met de UPN van de gebruiker?

[YaYo86]

Jazzy schreef op dinsdag 13 december 2016 @ 10:45:
Welke browser gebruik je? En er wordt ingelogd in Windows 10 met de UPN van de gebruiker?

Varieerd, ene gebruiker gebruikt Edge, andere weer FF en/of Chrome. De ervaring is met elke browser hetzelfde.

Ja er wordt ingelogd met de UPN in Windows 10.

[Jazzy]

Open dan in ieder geval even een support request. Mocht je er hier niet uitkomen, dan wordt er door Microsoft ook aan gewerkt.

[YaYo86]

Oke ga ik even doen, echter zoals eerder aangegeven denk ik dat MS ook zal zeggen dat ADFS nodig zal zijn maar we gaan het zien!

[Vincent17]

YaYo86 schreef op dinsdag 13 december 2016 @ 10:40:
[...]

Dat is dus std niet het geval, credentials moeten 2x worden opgegeven.

Bij een juiste inrichting is dit juist wel standaard het geval. Zie:

https://docs.microsoft.co...tory-azureadjoin-overview

Dit is ook mijn eigen ervaring.