SSO via Saml/AzureAD

[brianb]

Hi,

We syncen via onze lokale AD de users naar AzureAD (op dit moment alleen de users o.b.v. een P1 licentie, omdat we nog niet zo ver zijn).
Vervolgens heb ik een Bedrijfsapplicatie aangemaakt, waarop de leverancier van de cloud applicatie gekoppeld heeft (als ik het zo goed verwoord, we zijn nog niet zo vaardig op dit gebied). Tot dus ver werkt het ook, deze users heb ik rechten gegeven op deze bedrijfs app.

Vorige keer heb ik hier een topic over geopend, hoe deze sync überhaupt mogelijk te maken en dat is nu wel gelukt door Onprem AD > AzureAD > Bedijfstoepassing.

Op deze reply-url e.d. sluiten zij dan aan (ik weet niet wat er aan de leverancierskant moet gebeuren).

Mijn gebruikers kunnen de rechtstreekse SSO url van de leverancier benaderen, en ook inloggen, ECHTER alleen als ze de eerste keer hun email adres(=upn) en ww invullen. Dit is maar een eenmalige actie, waar ik zelf mee kan leven, maar mijn manager vindt dit GEEN SSO, waardoor het project vertraging oploopt.

Weet iemand van jullie, waar dit door komt? Is dat omdat we niet volledig in Azure zitten, maar hybride werken? Niemand werkt in portal.office.com e.d. dus er is in principe niemand geautentiseerd... (alleen bekend in AzureAD)

De leverancier zegt dit:

Blijkbaar bent u op het moment van aanmelden bij de applicatie nog niet geauthentiseerd bij de identity provider(in dit geval Azure AD), daarom wordt u gevraagd om uw domein credentials op te geven. Als u al wel geauthentiseerd bent bij de identity provider dan hoeft u niet uw domein credentials op te geven.

Een voorbeeld is office365, sommige klanten die melden zich gelijk aan bij office365 met hun domein credentials en daarmee hebben ze ook gelijk toegang tot de applicatie aangezien office365 en de applicatie gebruik maken van dezelfde identity provider(in dit geval Azure AD).

Zoals gezegd, ik ben er helaas nog niet vaardig genoeg in, maar weet iemand of we de ''no klik'' SSO voor elkaar kunnen krijgen zoals mijn manager wilt?

[nextware]

Begrijp ik het goed dat je binnen Azure een Enterprise app hebt aangemaakt ? Hierin heb je dan de metadata file van je leverancier ingevoerd ?

Als je dan in de eigenschappen van je Enterprise app kijkt, heb je onder Properties de "User Access URL" staan. Wat gebeurd er als je deze URL in een browser plakt ?

[brianb]

nextware schreef op woensdag 27 mei 2020 @ 15:29:
Begrijp ik het goed dat je binnen Azure een Enterprise app hebt aangemaakt ? Hierin heb je dan de metadata file van je leverancier ingevoerd ?

Als je dan in de eigenschappen van je Enterprise app kijkt, heb je onder Properties de "User Access URL" staan. Wat gebeurd er als je deze URL in een browser plakt ?

Hi, ik heb vooral data aan hen moeten aanleveren uit het SAML gebaseerde aanmelding tabblad. En hier ook enkele moeten toevoegen.

Was ff vertalen (staat op NL), maar ik heb inderdaad onder de bedrijfstoepassing en dan eigenschappen een ''URL van gebruikerstoegang''. Als ik die URL aanroep, moet ik een keer met email adres en ww inloggen (log in van een werkplek waar dus nog niet aan azure gekoppeld is), ben ik inderdaad meteen ingelogd.

Maar dat gebeurt in principe met de link die zij mij hebben gedeeld ook. Deze zal wel naar dit pad verwijzen lijkt me? Kan je hier iets mee? Ik kom in ieder geval daarmee op dezelfde plek uit als wanneer ik de Antwoord-URL open.(dat is waar de applicatie bij de leverancier draait).

Maar al met al, ik moet dus via die Url van gebruikerstoegang als nog een keer het emailadres en ww invullen en dat wil mijn manager niet ....

[nextware]

Heb je de door de leverancier aangeleverde metadata file ingeladen in je enterprise app binnen Azure ?
En heb je jouw metadata file aangeleverd icm certificaten bij je leverancier?

En uiteraard moet je device en user ook wel in Azure AD bekend zijn omdat Azure je aanmelding verzorgt bij die app..

[ralpje]

Welke manier van authenticatie op AAD gebruik je? Gebruik je iets van ADFS of pass-through authenticatie, of wordt authenticatie volledig door de cloud afgehandeld?
En het device waar je mee werkt, is dat (hybrid) AAD joined, of hangt die alleen aan je on-prem domain?

[brianb]

nextware schreef op woensdag 27 mei 2020 @ 21:36:
Heb je de door de leverancier aangeleverde metadata file ingeladen in je enterprise app binnen Azure ?
En heb je jouw metadata file aangeleverd icm certificaten bij je leverancier?

En uiteraard moet je device en user ook wel in Azure AD bekend zijn omdat Azure je aanmelding verzorgt bij die app..

Ik heb geen metadata file gekregen van hem. Ik heb alleen aan hem URL van gebruikerstoegang, antwoord url e.d. van onze Azure portal aangeleverd. Hij zal hier op verbonden hebben?
M.b.t. certificaten hebben wij niks aangeleverd. Volgens mij gebeurt dat binnen hun hosting?

Bekend zijn in AzureAD zeg je? We syncen alle users vanuit onze onprem AD naar AzureAD. Daar zijn ze allemaal bekend. Echter hun devices (on-prem gekoppelde domein pc's) zijn niet bekend in AzureAD. Moeten/Hoe sync je die dan richting AzureAD? Is dat niet alleen de users?

ralpje schreef op woensdag 27 mei 2020 @ 21:39:
Welke manier van authenticatie op AAD gebruik je? Gebruik je iets van ADFS of pass-through authenticatie, of wordt authenticatie volledig door de cloud afgehandeld?
En het device waar je mee werkt, is dat (hybrid) AAD joined, of hangt die alleen aan je on-prem domain?

We gebruiken pass-through authenticatie. Users zijn dus gesynct naar AAD met bijbehorende data. Het moment dat ik bij een eindgebruiker de url van de cloud app open, kom ik bij de ''microsoft login' pagina uit kan daar met het bijbehorende emailadres en ww van de gebruiker inloggen. Hij is dus bekend in AAD.
Leverancier heeft ook een SSO link aangeleverd en zegt als ze die openen ze er direct in landen. Echter moeten ze zich altijd 1x autentificeren. Daarna logt die inderdaad rechtstreeks in.

En ja, wat je zegt, de devices hangen aan ons on-prem domain. Er is niks aan het AAD domein gekoppeld, hier zijn dus alleen de users heen gesynct.

Is dit zo wat duidelijker?

[nextware]

Ik heb geen metadata file gekregen van hem. Ik heb alleen aan hem URL van gebruikerstoegang, antwoord url e.d. van onze Azure portal aangeleverd. Hij zal hier op verbonden hebben?
M.b.t. certificaten hebben wij niks aangeleverd. Volgens mij gebeurt dat binnen hun hosting?

Om een Enterprise app binnen Azure via SSO te kunnen koppelen zijn er wel een aantal vereisten nodig:

- Metadata XML bestand van de leverancier: dit laadt je in bij de Enterprise app in JOUW Azure omgeving. Dit levert je de Identifier (niet verplicht) en Reply URL op (eventueel kan dit handmatig zoals in jouw geval, maar verhoogt wel de kans op fouten)

- Metadata XML + certificaten uit JOUW Azure omgeving: dit lever je aan bij de leverancier die dit op zijn beurt weer importeert in zijn (web) applicatie

Daarnaast kan het zijn dat je wellicht nog wat claims mee moet geven tijdens authenticatie, zoals group claims, etc. Dit is echter wel optioneel..

In de Metadata XML file die JIJ dan aanlevert staan de benodigde info waarmee zijn systeem jouw users kan authenticeren via SSO. Mijn vermoeden is dat hier nog iets niet geheel goed staat..

[brianb]

Hey is inmiddels gelukt.
De Metadata, bedrijfsapplicatie etc. waren in orde.

Wat er nog moest gebeuren was:
1) een aanpassing in de GPO's van onze on-prem domain controller:

Windows Components/Internet Explorer/Internet Control Panel/Security Page/Intranet Zone

Allow updates to status bar via script Enabled
Status bar updates via script Enable

Logon options Enabled
Logon options Automatic logon with current username and password


2) deze links in de Trusted Intranet zone zetten:
-https://aadg.windows.net.nsatc.net
-https://autologon.microsoftazuread-sso.com
-de saml link van de applicatie / azure bedrijfsapplicatie.

3) AzureAD connect stond op password hash, maar nog geen vinkje bij SSO. Deze aangezet.

Na deze 3 handelingen snapt de browser dat hij zich moet identificeren en logt hij automatisch door.

Thnx allen voor de hulp!