Automatisch aanmelden Office 365

[Massiefje]

Voor een klant heb ik een klein stukje code geschreven dat via username en wachtwoord authenticeert tegen Exchange 2010, waarna de gebruiker automatisch ingelogd wordt in Outlook Web Access. Dit werkt prima en naar tevredenheid. Echter, ze lonken nu naar het gebruik van Office 365. En dit systeem willen ze ook graag gaan gebruiken in Office 365.

Ik loop er nu tegenaan dat ik door de bomen het bos niet meer zie. Wat we hebben is een username en wachtwoord binnen Office 365. Die hebben wij als, laten we zeggen, Office 365 admins. Deze username en dit wachtwoord krijgen de gebruikers niet. Zij loggen in op het intranet en zouden dan via een link automatisch aangemeld moeten worden op Office 365 Exchange, zonder extra login scherm!

Er zal wel een koppeling zijn tussen de Azure AD en de interne AD, echter, naar deze logica hoeft niet gekeken te worden, want we willen de users laten connecten naar een andere mailbox dan hun eigen mailbox. Dus het is niet zo dat ze hun eigen mailbox te zien moeten krijgen in Office 365. Dan zou het een heel ander verhaal zijn. Als voorbeeld willen we gebruiker [e-mail] laten connecten naar [e-mail].

Waar ik me al op ingelezen heb is OAuth/OAuth2, maar dit lijkt het doel volledig voorbij te schieten (of toch niet?)

De intranet site is gebouwd op basis van ASP.NET met C# als achterliggende taal.

Wie kan me de juiste kant op sturen voor dit lastige, maar wellicht toch makkelijke, vraagstuk?

Even ter volledigheid: het gaat hier niet om het omzeilen van Office365 licenties, maar om het gebruik van shared mailboxen voor specifieke users.

[418O2]

Heb je al gezocht op single sign on? Dat zou je probleem moeten oplossen. OAuth is er overigens ook prima voor geschikt

[Wish]

OAuth, SAML2.0, Single Sign On, allemaal termen om je in in te lezen. Als je zowel een AD als een AAD aan het draaien bent, kijk dan vooral ook even naar deze (redelijk recente) implementatie:
https://docs.microsoft.co...ss-through-authentication

[Massiefje]

Er is 1 ding nog niet gemeld: de clients melden aan op een intranet site, waar ze een AD login/password moeten ingeven. Dit moeten ze, omdat de PC waar ze mee werken, geen onderdeel is van het AD. Dit is iets wat ook niet aangepast gaat worden en heeft valide redenen.

Kortom: gebruiker is aangemeld op AD via een intranetsite die draait op IIS.

[DJMaze]

Wees creatief zou ik zeggen. Alles is altijd mogelijk (ook al zegt men van niet).
De vraag is hoeveel tijd je mag besteden.

[ Voor 104% gewijzigd door DJMaze op 05-04-2018 18:50 ]

[Wish]

Massiefje schreef op donderdag 5 april 2018 @ 11:48:
Er is 1 ding nog niet gemeld: de clients melden aan op een intranet site, waar ze een AD login/password moeten ingeven. Dit moeten ze, omdat de PC waar ze mee werken, geen onderdeel is van het AD. Dit is iets wat ook niet aangepast gaat worden en heeft valide redenen.

Kortom: gebruiker is aangemeld op AD via een intranetsite die draait op IIS.

Dan nog - of een machine domain joined is of niet: lees over SSO, SAML2.0, OAuth en mijn andere tip...

[Sandor_Clegane]

Massiefje schreef op donderdag 5 april 2018 @ 11:33:
snip

Voor het aanmelden van gebruikers zal er een schaduw-account zijn dat gebruikt wordt op de achtergrond om zich op Office 365 aan te melden.

Deze schaduw accounts worden gesynct met de lokale AD. Wil je het jezelf gemakkelijk maken dan zou ik het lokale account dat je nu gebruikt voor de lokale Exchange server ook syncen met O365 en dit account rechten geven op de Office 365 resources.

Als het goed is kun je dan gewoon piggybacken op de normale autorisatie en authenticatie methodes van O365.

[Massiefje]

Ik ben er nu een tijd mee bezig geweest, mezelf op allerlei zaken ingelezen en daarbij ook een hoop voorbeelden geprobeerd, maar ik kom er maar niet uit.

Ik kan prima authenticeren tegen Office 365 aan, maar die authenticatie is allemaal server based. Mijn server lijkt dus authenticated te zijn.

Wat wij willen is de de gebruiker autenticated is, als hij op een link in ons intranet klikt. Ik zal in het kort nog even wat stappen uitleggen, waardoor e.e.a. misschien duidelijker wordt.

1. Er draait een intranet-site onder (bv) https://intranet.domain.com
2. Op dit intranet is de gebruiker automatisch ingelogd, vanwege de interne AD en de IIS authentication instellingen
3. De gebruiker ziet een link: Webmail
4. De gebruiker klikt op de link en gaat automatisch naar het door ons ingestelde Office 365 Exchange Online toe.
5. Hij hoeft GEEN username en wachtwoord in te tikken, want die kent hij niet. Wij als programmeurs wel

De problemen waar ik tegenaan loop:
- Authenticeren lukt, maar browsersessie/user is niet authenticated, maar de intranet site zelf
- Er is geen koppeling (mogelijk) tussen interne AD en Azure AD.

Is dit uberhaubt wel mogelijk, begin ik mezelf af te vragen.

Kan iemand me nog wat gedetailleerder op weg helpen?

[Sandor_Clegane]

Massiefje schreef op dinsdag 10 april 2018 @ 14:02:
Snip

Dit is niet SSO als ik het zo lees, maar het proxyen van de verbinding naar O365. Als je dit wilt doen zal jouw applicatie als een man in the middle moeten fungeren en alle requests afhandelen en deze weer terugspelen naar de gebruiker..

Je zult dus op je intranet site een usermap moeten hebben van AD --> Azure, autorisatie doen, passwords bijhouden. Klinkt als iets voor Identity Integration Server, maar dat is ook geen kattenpis.

Dat is best een kluif.

[Massiefje]

Niemand die meer ervaring heeft met Office 365 authenticatie? En of dit uberhaubt mogelijk is?

[Laurens-R]

Als er geen koppeling mogelijk is tussen de local AD en Azure AD, zie ik niet zo 1..2..3 in hoe dit op een nette en veilige manier gaat lukken. Ergens moet de vertaalslag van je locale AD naar O365 AD user gemaakt worden en zonder koppeling is dat eigenlijk niet te doen; en dus moet een gebruiker apart inloggen.

In mijn optiek; als je een overstap op O365 gaat maken is het eigenlijk een vereiste wmb dat er ook een koppeling tussen de AD's gemaakt word (al dan niet via tunnels etc).

Je O365 identity kan vervolgens toegang krijgen tot een aparte support mailbox oid. Maar zonder AD integratie kan je niet automatisch naar de betreffende mailbox getransporteerd worden. Je kan uiteraard een O365 identity aanmaken en men daar mee laten inloggen op de aparte mailbox; maar ja dat is dan weer niet volledig automatisch en dus niet wenselijk binnen jouw requirements.

Ik zat nog even naar ADAL te kijken (een library voor Azure AD authenticatie), maar dat lijkt meer gericht te zijn op App authenticatie die je vervolgens kan gebruiken voor REST endpoints, wat niet gaat werken als je mensen echt wilt laten inloggen op O365 Outlook oid.

[ Voor 41% gewijzigd door Laurens-R op 18-04-2018 13:13 ]

[Killah_Priest]

Laurens-R schreef op woensdag 18 april 2018 @ 13:07:
Als er geen koppeling mogelijk is tussen de local AD en Azure AD, zie ik niet zo 1..2..3 in hoe dit op een nette en veilige manier gaat lukken. Ergens moet de vertaalslag van je locale AD naar O365 AD user gemaakt worden en zonder koppeling is dat eigenlijk niet te doen; en dus moet een gebruiker apart inloggen.

In mijn optiek; als je een overstap op O365 gaat maken is het eigenlijk een vereiste wmb dat er ook een koppeling tussen de AD's gemaakt word (al dan niet via tunnels etc).

Je O365 identity kan vervolgens toegang krijgen tot een aparte support mailbox oid. Maar zonder AD integratie kan je niet automatisch naar de betreffende mailbox getransporteerd worden. Je kan uiteraard een O365 identity aanmaken en men daar mee laten inloggen op de aparte mailbox; maar ja dat is dan weer niet volledig automatisch en dus niet wenselijk binnen jouw requirements.

Ik zat nog even naar ADAL te kijken (een library voor Azure AD authenticatie), maar dat lijkt meer gericht te zijn op App authenticatie die je vervolgens kan gebruiken voor REST endpoints, wat niet gaat werken als je mensen echt wilt laten inloggen op O365 Outlook oid.

Je kunt geen "koppeling" maken tussen je on-prem AD en Azure AD met een tunnel, dit loopt via dirsync. Dit is eigenlijk de enige manier om je on-prem identities in 365/AzureAD te krijgen.

Wat ik niet begrijp uit het verhaal van de TS is waarom er niet gekeken hoeft te worden naar de koppeling tussen de lokale AD en AzureAD : de logica ontgaat mij compleet. Toegang tot een andere mailbox kan immers prima met je eigen AD / AzureAD identity, je kunt namelijk users gewoon machtigen op een mailbox. Ik kan met mijn office365 account gewoon mailboxen openen waarop ik toegang heb, via Outlook, OWA, EWS en de Outlook Online REST API).
Zodra een user authenticated is binnen 365 (waarvoor je eventueel weer lokaal GPO'S in kunt richten voor SSO bij domain joined machines, iets wat zonder domein in feite ook wel kan maar dan zonder GPO'S) kan een user binnen dezelfde sessie alle andere 365 zaken uitvoeren, inclusief een directe link naar de OWA van de betreffende mailbox.


Overigens zie ik wat tegenstrijdigheden in het verhaal : in de ene post geeft de TS aan dat men in moet loggen op de intranet site omdat de machines geen onderdeel uitmaken van een AD : vervolgens wordt er in een andere post aangegeven dat men automatisch inlogt op de intranet site vanwege de interne AD.
Tevens wordt er in de eerste post aangegeven dat er een koppeling is tussen de on-prem AD en AzureAD, in een latere post staat er dat er geen koppeling mogelijk is tussen deze ADs.

Probeer eerst alles voor jezelf duidelijk op papier te zetten, ik begrijp nu echt niet meer wat je precies probeert te doen en op welke manier. Ook snap ik de "valide" reden niet om de machines geen onderdeel uit te laten maken van het domein, het klinkt alsof dit om security redenen is, echter wordt het er op de huidige manier echt niet veiliger op (integendeel zelfs). Is dit nog toe te lichten? Wat voor jou valide lijkt hoeft niet altijd zo te zijn. Binnen een AD omgeving kun je immers met meerdere domeinen werken (al dan niet binnen een enkele forest of meerdere forests of zelfs een apart domein met een trust relationship zodat je gewoon met een account uit domein A op een machine welke aan domein B gekoppeld is in kunt loggen. Ik.kan gewoon geen enkele valide reden bedenken behalve onwetendheid of er geen geld aan uit kunnen of willen geven).

Met alle respect, de huidige oplossing komt op mij redelijk houtje touwtje over en opgezet door mensen die weinig inhoudelijke kennis hebben van AD en Exchange (en dat bedoel ik dan echt niet lullig of om jou of je bedrijf af te zeiken, ieder zo zijn specialiteit binnen de IT. De mijne ligt juist bij AD, AzureAD, ADFS, Exchange etc. IIS ben ik echter weer een stuk minder in bijvoorbeeld terwijl anderen die geen zak van Azure weten daar bv wel weer alles van weten en daar goed in zijn. Het lastige met dit spul is dat MS van een developer verwacht dat deze ook weet hoe je zaken moet doen welke normaal toch echt door systeembeheerders gedaan worden).

Als er wat meer duidelijk is over de situatie dan help ik je met alle plezier.

[ Voor 59% gewijzigd door Killah_Priest op 18-04-2018 23:23 ]

[Laurens-R]

Killah_Priest schreef op woensdag 18 april 2018 @ 21:53:
[...]


Je kunt geen "koppeling" maken tussen je on-prem AD en Azure AD met een tunnel, dit loopt via dirsync. Dit is eigenlijk de enige manier om je on-prem identities in 365/AzureAD te krijgen.

ik probeerde het idee erachter aan te geven. maar nu je toch erover begint (te muggenziften): dirsync word sinds april 2017 niet meer gesupport. je moet Azure AD connect gebruiken. zie ook https://docs.microsoft.co...tive-directory-aadconnect

azure ad connect heeft sync services. grofweg kan je dat wat mij betreft als een soort van koppeling beschouwen.

[Killah_Priest]

Laurens-R schreef op donderdag 19 april 2018 @ 07:12:
[...]


ik probeerde het idee erachter aan te geven. maar nu je toch erover begint (te muggenziften): dirsync word sinds april 2017 niet meer gesupport. je moet Azure AD connect gebruiken. zie ook https://docs.microsoft.co...tive-directory-aadconnect

azure ad connect heeft sync services. grofweg kan je dat wat mij betreft als een koppeling beschouwen.

De techniek heet dirsync (hoewel men nogal vaak de naam van zaken wilt wijzigen bij MS), de tool heet AAD connect. De tool synched de ADs.
In de O365 portal heeft men het nog steeds over dirsync errors, last dirsync etc, ookal gebruik je AAD connect.

De reden dat ik het zo benoem is om te voorkomen dat de TS bv een site 2 site vpn op gaat zetten naar Azure om identities te syncen.

En ik probeer de ts gewoon te helpen (hoewel ik nogal bot over kom : mijn intenties zijn gewoon goed)

[ Voor 27% gewijzigd door Killah_Priest op 19-04-2018 09:52 ]

[Massiefje]

Killah_Priest schreef op woensdag 18 april 2018 @ 21:53:
[...]
Als er wat meer duidelijk is over de situatie dan help ik je met alle plezier.

Ondanks dat ik de opdracht inmiddels 'uit handen gegeven heb', wil ik toch nog even reageren op Killah_Priest. Wel zo netjes, aangezien hij een zeer uitgebreid antwoord heeft gegeven op een zeer nette manier.

De tegenstrijdigheid komt voort uit het feit dat er 100+ vestigingen zijn. Deze zijn via een KPN netwerk verbonden met het hoofdkantoor (waar ik werk). Echter, de PC's in de vestigingen zijn niet van het hoofdkantoor, maar eigenlijk van een 3e partij nog. Deze derde partij zorgt voor alle automatisering in de vestigingen, waardoor deze GEEN aanmelding op het domein hebben.

De tegenstrijdigheid is, dat op het hoofdkantoor de mensen uiteraard WEL automatisch op het intranet aangemeld worden via IIS, maar dat een vestiging dan wel eerst moet inloggen. IIS kent gebruiker 'workgroup\xyz' niet, uiteraard.

Hopelijk maakt dit het verhaal iets duidelijker. Sorry voor de onduidelijkheid, maar ik wil niet teveel details prijsgeven, waardoor het soms niet helemaal duidelijk is.

[Killah_Priest]

Massiefje schreef op woensdag 25 april 2018 @ 11:55:
[...]


Ondanks dat ik de opdracht inmiddels 'uit handen gegeven heb', wil ik toch nog even reageren op Killah_Priest. Wel zo netjes, aangezien hij een zeer uitgebreid antwoord heeft gegeven op een zeer nette manier.

De tegenstrijdigheid komt voort uit het feit dat er 100+ vestigingen zijn. Deze zijn via een KPN netwerk verbonden met het hoofdkantoor (waar ik werk). Echter, de PC's in de vestigingen zijn niet van het hoofdkantoor, maar eigenlijk van een 3e partij nog. Deze derde partij zorgt voor alle automatisering in de vestigingen, waardoor deze GEEN aanmelding op het domein hebben.

De tegenstrijdigheid is, dat op het hoofdkantoor de mensen uiteraard WEL automatisch op het intranet aangemeld worden via IIS, maar dat een vestiging dan wel eerst moet inloggen. IIS kent gebruiker 'workgroup\xyz' niet, uiteraard.

Hopelijk maakt dit het verhaal iets duidelijker. Sorry voor de onduidelijkheid, maar ik wil niet teveel details prijsgeven, waardoor het soms niet helemaal duidelijk is.

Verstandig om dit uit handen te geven : Office 365 (en dan voornamelijk AzureAD waar het allemaal op leunt) kan erg ingewikkeld zijn. Als je daar niet dagelijks mee bezig bent dan kost het je gewoon teveel tijd om dit soort zaken fatsoenlijk in te richten, helemaal bij een setup als welke je omschrijft.

(ik zit zelf ook met 100+ vestigingen, echter zijn bij mij alle machines gelukkig domain joined wat het beheer een stuk gemakkelijker maakt).