O365: Same Sign On

Door ralpje op dinsdag 4 juni 2013 08:32 - Reacties (4)
Categorieën: ActiveDirectory, Office365, Views: 3.505

Voor klanten die graag Office 365 gebruiken maar niet graag werken met 'gescheiden' passwords voor de on-premise omgeving en die in cloud was er tot nu toe één optie: Door middel van ADFS en DirSync de gegevens van je on-premise AD syncen naar de cloud en daarmee ook je (kerberos)authenticatieticket synchroniseren. Eén keer inloggen en je bent geauthenticeerd op beide omgevingen.
Ideaal natuurlijk, maar ook een behoorlijk uitgebreide setup: je zult de ADFS rol ergens moeten implementeren, je zult een ADFS-proxy moeten inrichten én je moet DirSync kunnen draaien. De laatste twee rollen kun je niet elkaar óf met een domain controller combineren, waardoor je flink zult moeten investeren in servers.... en die wilde je nou net kwijt met je overstap naar de cloud.

Inmiddels heeft Microsoft hier een mooi alternatief voor gevonden: Password Synchronization. Deze extra functie in de nieuwe versie van DirSync bied de mogelijkheid om door middel van een zogenaamde password hash sync je on-premise password te syncen naar de cloud.
Dat syncen geeft ook gelijk aan wat het grootste nadeel is: er is géén single sign on. Je password wordt (gehashed, uiteraard) gesynchroniseerd vanuit de on-premise AD naar de cloud, maar er vindt geen synchronisatie plaats tussen (bijvoorbeeld) kerberostickets.
Het voordeel is echter dat je het password tussen beide omgevingen gelijk trekt en je dus bij een expired password maar op één plaats je password hoeft te wijzigen (en te onthouden ;)) én dat er minder ijzer nodig is om het te realiseren: de sync zit simpelweg in de nieuwste DirSync-versie en je hebt dus geen ADFS-Proxy of andere uitgebreide oplossingen nodig. Voor kleinere gebruikers die geen single sign on nodig hebben maar wel graag uniformiteit hebben in wachtwoorden is dit een prima optie en eens te meer toont Microsoft aan dat ze de markt goed in de gaten hebben en waar mogelijk hierop inspelen.

Mijn twee grootste wensen voor O365 op dit moment: Two-factor authentication (die nu in beta al voor admins beschikbaar is!) en self-service password recovery. Die laatste functie zit al deels in de nieuwste Wave 15 voor O365, maar uitsluitend voor admins. Ik verwacht dat Microsoft allebei deze functies voor het einde van dit kalenderjaar voor alle gebruikers heeft uitgerold.

Volgende: Vind de nerds in je Exchange-omgeving 09-'13 Vind de nerds in je Exchange-omgeving
Volgende: Een alias aan een mailbox toevoegen 05-'13 Een alias aan een mailbox toevoegen

Reacties


Door Tweakers user ItMeAedri, dinsdag 4 juni 2013 13:54

Dus... dit is een simpele versie van een single sign on?

Door Tweakers user i-chat, dinsdag 4 juni 2013 16:16

tja een betere implementatie zou toch zijn om gewoon een tunnel aan te leggen, en dus helemaal geen signon te gebruiken, maar in plaats daarvan authorisation dus gewoon door de locale server (via de tunnel) te laten uitvoeren.

google apps zit hier trouwens met het zelfde probleem maar bij hen is de service al een stuk langer in gebruik, jammer eigenlijk dat ms blijkbaar niet even heeft gekeken welke problemen de concurentie heeft om vervolgens met een briliante oplossing te komen.

kerberos delegation is trouwens een eitje, dus ik snap MS hier echt niet..

Door Tweakers user ralpje, dinsdag 4 juni 2013 21:12

@i-chat: Kerberos delegation is op zich een eitje, maar vereist in MS-implementatie nogal wat hard- en software waardoor het al snel niet rendabel is. Dit is op zich een mooi alternatief, zeker als het ook nog enigszins redundant moet zijn. Alleen een tunnel is dan al niet genoeg ;)

@Arnlith: het is geen échte single signo, je moet nog steeds op elke dienst apart inloggen. Wel wordt je password vanuit AD gesynct naar O365 en kun je dus overal met datzelfde password inloggen. Als je in AD je password wijzigt, wijzigt je password in O365 dus (binnen korte tijd) mee.

Door Tweakers user i-chat, woensdag 5 juni 2013 00:42

ralpje schreef op dinsdag 04 juni 2013 @ 21:12:
@i-chat: Kerberos delegation is op zich een eitje, maar vereist in MS-implementatie nogal wat hard- en software waardoor het al snel niet rendabel is. Dit is op zich een mooi alternatief, zeker als het ook nog enigszins redundant moet zijn. Alleen een tunnel is dan al niet genoeg ;)
voor redundancy heb je zowiso altijd 2 machines nodig zelfs al draai je op beiden esxi om vervolgens zoveel mogelijk machines op 1 box te proppen, maar het belangrijkste is, dat ms de hele kerberos gedachte aan het ver...{bleep}...en is! want voor kerberos heb je namelijk maar 2 machines nodig, of hooguit 3 als je het netjes doet... 1 authenticatie serice (bijv windows AD), 2 de machine die de tokens genereerd (zou ook op de AD kunnen draaien .... 3 de machine die navraag doet of de token wel geldig is...

het voornaamste probleem hier is dat MS graag extra afhankelijkheden wil creeren en dus hun eigen authorisatie service wil pushen, dan kom je al snel bij dit soort halfbakken oplossingen...

in heel veel mail omgevingen krijg je gewoon een aantal mailboxes toegewezen, als MS een en ander goed had uitgerolt dan zou je per mailbox hebben kunnen kiezen hoe AAA in zijn werk gaat..... local opgeslagen (msn account), remove via ldap of AD, via kerb of via x y z authenticatie methode...

dit is ook gelijk de reden waarom ik toch overweeg om af te stappen van google apps... same signon is niet goed genoeg (we leven immers niet meer in in 2002)

[Reactie gewijzigd op woensdag 5 juni 2013 00:42]


Reageren is niet meer mogelijk