Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

Azure AD verbinden met lokale AD omgeving

Pagina: 1
Acties:

  • birdie25
  • Registratie: Augustus 2009
  • Laatst online: 28-11 08:47
Ik ben aan het onderzoeken op welke manieren ik onze lokale AD omgeving kan verbinden met Azure AD om gebruikers met hun AD credentials bij cloudapplicaties in te laten loggen (SSO). Er ligt echter een enigzins harde eis op tafel dat er geen gebruikersdata mag worden gesynchroniseerd met de Microsoft Azure cloud.

Eerst heb ik gekeken naar een combinatie van AD/ADFS/Azure AD om zo een federated identity te creëren waarmee bij verschillende cloudapplicaties ingelogd kan worden met de bestaande AD credentials, alleen loop ik tegen een paar dingen aan:

Ten eerste de eis vanuit de organisatie dat er geen gebruikersgegevens de on-prem omgeving mogen verlaten, gaat dat uberhaupt werken met Azure AD? Naar mijn weten moeten er minstens een aantal attributen vanuit AD gesynchroniseerd worden met Azure om een federation te bewerkstelligen tussen ADFS en Azure AD.

Ten tweede, om Azure AD te verbinden met de lokale AD omgeving moet er gebruik gemaakt worden van Azure AD Connect, dit moet op een 2012R2 bak draaien met minimaal 4GB RAM. Is dit echt noodzakelijk of zijn er andere mogelijkheden?

Graag hoor ik jullie ervaringen met dit soort implementaties :)

http://specs.tweak.to/18230


  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 22:23

Jazzy

Moderator SSC/PB

Moooooh!

birdie25 schreef op vrijdag 27 november 2015 @ 14:41:
Ten eerste de eis vanuit de organisatie dat er geen gebruikersgegevens de on-prem omgeving mogen verlaten, gaat dat uberhaupt werken met Azure AD? Naar mijn weten moeten er minstens een aantal attributen vanuit AD gesynchroniseerd worden met Azure om een federation te bewerkstelligen tussen ADFS en Azure AD.
Dat klopt, je hebt het bijvoorbeeld over de UPN maar ook zaken als DisplayName. Je zou eerst even helder moeten krijgen wat jouw organisatie precies bedoelt met 'gebruikersgegevens'. Want het wordt vrij moeilijk om überhaupt een applicatie te configureren zonder basale eigenschappen als een naam te gebruiken. Of je dat nu automatisch doet of handmatig.
Ten tweede, om Azure AD te verbinden met de lokale AD omgeving moet er gebruik gemaakt worden van Azure AD Connect, dit moet op een 2012R2 bak draaien met minimaal 4GB RAM. Is dit echt noodzakelijk of zijn er andere mogelijkheden?
De term 'verbinden met' is vaag, je moet eigenlijk wat concreter zijn en uitleggen of je het hebt over het provisionen van accounts in de cloud service (synchronisatie) of bijvoorbeeld over authenticatie (synchroniseren van de password hash of ADFS).

De requirements voor Azure AD Connect staan hier: https://azure.microsoft.c...aadconnect-prerequisites/ Waar denk je precies aan als je vraagt of dit echt noodzakelijk is? Wil je met minder geheugen toe? Een ander operating system?

Exchange en Office 365 specialist. Mijn blog.


  • birdie25
  • Registratie: Augustus 2009
  • Laatst online: 28-11 08:47
Jazzy schreef op vrijdag 27 november 2015 @ 14:50:
[...]

Dat klopt, je hebt het bijvoorbeeld over de UPN maar ook zaken als DisplayName. Je zou eerst even helder moeten krijgen wat jouw organisatie precies bedoelt met 'gebruikersgegevens'. Want het wordt vrij moeilijk om überhaupt een applicatie te configureren zonder basale eigenschappen als een naam te gebruiken. Of je dat nu automatisch doet of handmatig.
Helder, bedankt ;)
Jazzy schreef op vrijdag 27 november 2015 @ 14:50:
De term 'verbinden met' is vaag, je moet eigenlijk wat concreter zijn en uitleggen of je het hebt over het provisionen van accounts in de cloud service (synchronisatie) of bijvoorbeeld over authenticatie (synchroniseren van de password hash of ADFS).

De requirements voor Azure AD Connect staan hier: https://azure.microsoft.c...aadconnect-prerequisites/ Waar denk je precies aan als je vraagt of dit echt noodzakelijk is? Wil je met minder geheugen toe? Een ander operating system?
Het gaat in dit geval om provisioning en authenticatie. We willen niet dat de password hash wordt gesynchroniseerd met Azure, zodoende dachten we aan ADFS als STS ;) Qua provisioning moet er dus bij elke nieuwe AD account ook een nieuwe Azure AD account aangemaakt worden, wat ook prima zou moeten werken.

Over de vraag over de requirements voor de AADConnect client had ik het meer over waarom zo'n applicatie nou precies 4GB RAM nodig zou hebben en of dat iemand ook inzicht kon bieden om het bijvoorbeeld op 2GB te draaien (wij betalen per GB aan RAM voor onze VM's).

http://specs.tweak.to/18230


  • Jazzy
  • Registratie: Juni 2000
  • Laatst online: 22:23

Jazzy

Moderator SSC/PB

Moooooh!

birdie25 schreef op vrijdag 27 november 2015 @ 15:02:
Over de vraag over de requirements voor de AADConnect client had ik het meer over waarom zo'n applicatie nou precies 4GB RAM nodig zou hebben en of dat iemand ook inzicht kon bieden om het bijvoorbeeld op 2GB te draaien (wij betalen per GB aan RAM voor onze VM's).
Als je ziet dat ze 4GB opgeven als eis voor een server tot circa 10.000 objecten dan zal het met minder objecten ook wel werken op een nog iets lichtere server. Maar je hebt het dus over ADFS die een database draait en dan nog de sync engine die ook een database draait. Dat zijn al met al best wat componenten op één server, als je dan ook nog het geheugen gaat halveren dan vraag ik me af of dit geen verkeerde zuinigheid is. Denk trouwens ook even na over de beschikbaarheid, als je maar één server in zet en die valt even uit dan hebben je gebruikers dus geen toegang meer tot de cloud applicaties. Om diezelfde reden hebben jullie intern immers ook meer dan één domain controller draaien.

Een ander aspect is externe toegang. Het wordt niet aanbevolen om je server met ADFS direct aan het internet te hangen maar om hiervoor een ADFS proxy in te zetten, bijvoorbeeld Server 2012 R2 met de Wep Application Proxy rol. En die heb je dan natuurlijk ook twee keer nodig.

Exchange en Office 365 specialist. Mijn blog.