ADFS met leverancier

[brianb]

All,

We gaan ons ticketsysteem voor IT migreren naar een cloud oplossing.
Nu wil de leverancier met onze AD koppelen via ADFS.
Zelf heb ik geen ervaring met ADFS, en hebben we tot dusver alleen een 1:1 VPN met Vodafone en daarover een domein trust, dus geen ervaring met ADFS.

Ik heb 2 Domein controllers (W2012), uiteraard gerepliceerd e.d.

Nu kan de partij waar we nu mee willen koppelen alleen met SAML2 omgaan en zo de SinglesignOn realiseren (want dit willen we uiteraard)

Zij vragen naar onze:

• FederationMetaData URL
• Preferred claim for example, windowsaccountname
• Domainaccount for test purposes

Concreet mijn vraag: kan ik zonder enkele enge gevolgen in mijn omgeving de ADFS rol installeren op de domein controller (of zelfs op beide?) en dan volgens deze video: YouTube: Installing ADFS on Windows Server 2012 R2 de rest afconfigureren?

ik ben er wat huiverig voor omdat ik er geen ervaring mee heb, en je vervolgens certificaten, A-records, IIS e.d. moet aanmaken.
Als ik dat al lees ben ik een beetje bang dat er iets anders gaat omvallen of gebruikers ineens niet meer kunnen inloggen e.d.

iemand die hier ervaring mee heeft of mij kan aangeven of ik de rol in ieder geval zonder dat er iets omkiept kan activeren en vervolgens de stappen kan volgen zoals hier gemeld?
SSL wildcard certificaat heb ik bij de hand dus kunnen we daar voor gebruiken.


Alvast bedankt voor de eventuele duwtjes in de goede richting.

[HyperBart]

Als je er bang voor bent dan ga je iemand moeten inhuren die er wel wat van kent, simpel .

Neen, het installeren van de ADFS rol op een DC is op zich niet iets wat dingen "kapot maakt"

Neen, het is absoluut geen goed idee. DC's zijn zowat de sleutelbewaarders van je rijk en die laat je liefst geen enkele andere rol vervullen.

Neen, het is absoluut geen goed idee om je ADFS servers die op een DC gaan draaien te publishen naar het internet.

Het beste wat je doet is een deployment guide zoals deze volgen:
https://docs.microsoft.co...-practices-securing-ad-fs

Hoe dan ook heb je naar mijn mening extra server instanties nodig (virtueel of fysiek, dat moet je zelf maar bekijken)
In de absolute minimumconfig heb je dus 2 servers nodig, eentje in je DMZ en eentje in je server-segment. Voor high availability (redundantie) zou je naar 4 servers moeten kijken...

[ Voor 12% gewijzigd door HyperBart op 02-04-2020 09:20 ]

[brianb]

hi HyperBart,

dat zijn duidelijk antwoorden, dankje!

De applicatie draait nu nog on-prem, op een 2016 server. Ik zou er dus voor kunnen kiezen om op deze server de ADFS rol toe te voegen. Zo heb ik hem niet op de DC's draaien.
Creeer ik alleen geen HA omdat hij alleen daar op draait, maar het is een ondersteunende applicatie, geen primaire applicatie.

Praktisch gezegd, en om het makkelijkste te houden, kan ik de rol op die huidige applicatieserver activeren en hier het certificaat e.d. op aanmaken. Dan ben ik ook niet op de DC's aan het ''kloten''

[hhoekstra]

Je moet intern een adfs server opzetten. Dan heb je een web proxy server nodig voor de buitenwereld.

https://docs.microsoft.co...-practices-securing-ad-fs

zie plaatje.

[Bor]

ADFS op een DC is doorgaans geen goed idee. Daarbij wil je de ADFS servers redundant uitvoeren waarschijnlijk. Je hebt dan ook iets van load balancing nodig. Wat betreft de oplossing; Microsoft heeft duidelijke documentatie en richtlijnen op dit gebied. Dat raad ik meer aan dan het volgen van youtube video's van 3e partijen welke soms outdated informatie laten zien of slechte keuzes maken.

[brianb]

Hmm, dit vergt toch nog een behoorlijk onderzoek.
Altijd fijn de leveranciers met opmerkingen zoals "Ja we koppelen met alle organisaties, zo 1-2-3"

Toch bedankt zover voor de antwoorden. Ik merk alweer dat dit nog een staartje gaat krijgen

[Bor]

brianb schreef op donderdag 2 april 2020 @ 09:48:
Hmm, dit vergt toch nog een behoorlijk onderzoek.
Altijd fijn de leveranciers met opmerkingen zoals "Ja we koppelen met alle organisaties, zo 1-2-3"

Toch bedankt zover voor de antwoorden. Ik merk alweer dat dit nog een staartje gaat krijgen

Veel organisaties, zeker grotere, hebben dit ook gewoon draaien. Het is geen rocket science maar je moet wel even goed over het ontwerp nadenken. Denk ook even goed na over patchprocedures etc.

[ Voor 4% gewijzigd door Bor op 02-04-2020 09:52 ]

[Xelefim]

In ons geval bij alle klanten met een ADFS setup:

FIREWALL -> WEB APPLICATION PROXY (not domain joined) -> ADFS -> AD

Dit zijn telkens aparte servers.

Opmerking: Het is aangeraden om alle HTTPS services te moeten forwarden naar je WAP (dus ook je mogelijke OWA/RDP/...). Je interne DNS moet dus goed staan en aangezien wij de WAP nooit in het domein zetten, zetten we de DNS in de hosts file van de WAP-server.

[HyperBart]

brianb schreef op donderdag 2 april 2020 @ 09:48:
Hmm, dit vergt toch nog een behoorlijk onderzoek.
Altijd fijn de leveranciers met opmerkingen zoals "Ja we koppelen met alle organisaties, zo 1-2-3"

Toch bedankt zover voor de antwoorden. Ik merk alweer dat dit nog een staartje gaat krijgen

Niet slecht bedoeld maar zo eenvoudig is het meestal wel en dat is een "industry standard solution" om single sign on / centralere authenticatie te regelen . Ik denk dat jullie hier gewoon (door jullie beperkte grootte van bedrijf?) een beetje in "achter lopen" of simpelweg de voorzieningen niet voor hadden.

@Bor gaf het ook al aan, het is geen rocketscience maar je moet er goed over nadenken en die link die ik in mijn eerste post aangaf dat is een héél goede uitwerking er van waar je niet beschaamd om moet zijn.

Aan de andere kant is een ADFS voor jullie voor alleen die applicatie "in de cloud" wat veel overhead voor jullie misschien. Kunnen ze niks door bv. het in Azure te publiceren en je identiteiten daar naar toe te synchroniseren en de cloud applicatie aldaar toe te voegen? Ik roep maar wat, ik snap dat die leverancier ook graag werkt met een standaard oplossing voor zichzelf.

[ Voor 17% gewijzigd door HyperBart op 02-04-2020 10:21 ]

[brianb]

HyperBart schreef op donderdag 2 april 2020 @ 10:18:
[...]

Niet slecht bedoeld maar zo eenvoudig is het meestal wel en dat is een "industry standard solution" om single sign on / centralere authenticatie te regelen . Ik denk dat jullie hier gewoon (door jullie beperkte grootte van bedrijf?) een beetje in "achter lopen" of simpelweg de voorzieningen niet voor hadden.

@Bor gaf het ook al aan, het is geen rocketscience maar je moet er goed over nadenken en die link die ik in mijn eerste post aangaf dat is een héél goede uitwerking er van waar je niet beschaamd om moet zijn.

Aan de andere kant is een ADFS voor jullie voor alleen die applicatie "in de cloud" wat veel overhead voor jullie misschien. Kunnen ze niks door bv. het in Azure te publiceren en je identiteiten daar naar toe te synchroniseren en de cloud applicatie aldaar toe te voegen? Ik roep maar wat, ik snap dat die leverancier ook graag werkt met een standaard oplossing voor zichzelf.

Thanks man! Nee, ik vat het ook zeker niet slecht op.
En ja, we lopen ''behoorlijk'' achter v.w.b. dit. Ik ben hier nu pas 4 jaar in dienst, maar toen ik kwam waren er nog 2003 servers, oude citrix omgeving (xenapp 6.5) nog steeds actief op dit moment, en veel verouderd.
Er heerste hier de gedachte waar ik behoorlijk kippenvel van krijg: "If it aint broke, dont fix it"
En achter die feiten hobbelen we nu aan...

Ik ga denk ik de huidige applicatie server hier voor ombouwen, als de ADFS dan daarop ingericht is, kan ik hem downscalen qua performance, aangezien hij dan alleen nog maar deze rol vervult. Dan hoeft het niet op de Dc's.

Voordat ik dat doe ga ik ze wel vragen of ze het niet in Azure kunnen publiceren en dan kunne we de users daarheen syncen.


Wordt nog een uitdaging, maar met jullie links moet het lukken.

[Killah_Priest]

Als je Office 365 gebruikt dan kun je dit binnen AzureAD doen zonder een eigen ADFS server.

Exacte details mbt hoe en wat weet ik niet meer precies, laatste keer dat ik dit heb moeten doen is al enkele jaren geleden.

[ Voor 41% gewijzigd door Killah_Priest op 02-04-2020 11:51 ]

[brianb]

Killah_Priest schreef op donderdag 2 april 2020 @ 11:49:
Als je Office 365 gebruikt dan kun je dit binnen AzureAD doen zonder een eigen ADFS server.

Exacte details mbt hoe en wat weet ik niet meer precies, laatste keer dat ik dit heb moeten doen is al enkele jaren geleden.

Helaas hier nog geen Office 365

[Dobey]

Het is inderdaad het simpelste om "gewoon" een losse ADFS server op te zetten. WAP in DMZ zone en je bent er.. Daarna je RP's aanmaken en feest is gevierd.

[KnoxNL]

Ik zou in het verlengde van @Killah_Priest niet meer investeren in ADFS.

Het is een brakke oplossing, die je veel tijd en energie kost om in te richten en te beheren, terwijl dit soort dingen prima via Azure AD kunnen.

ADFS is eigenlijk al niet meer van deze tijd, wij hebben het daarom +/- een half jaar geleden afgebouwd.

[Dobey]

Moet je natuurlijk wel al een AzureAD hebben draaien, als je dat niet hebt dan ben je toch nog toegewezen aan ADFS.

[KnoxNL]

Dobey schreef op donderdag 2 april 2020 @ 13:30:
Moet je natuurlijk wel al een AzureAD hebben draaien, als je dat niet hebt dan ben je toch nog toegewezen aan ADFS.

Of iets als Okta,

hoef je iig on-prem niet moeilijk te doen.

https://www.okta.com/inte...urce=google&utm_term=adfs

[Dobey]

KnoxNL schreef op donderdag 2 april 2020 @ 13:33:
[...]

Of iets als Okta,

hoef je iig on-prem niet moeilijk te doen.

https://www.okta.com/inte...urce=google&utm_term=adfs

Eens is ook een goede oplossing. Maar hoe dan ook moet de topicstarter zich even in lezen in de gekozen oplossing

[KnoxNL]

Dobey schreef op donderdag 2 april 2020 @ 13:36:
[...]


Eens is ook een goede oplossing. Maar hoe dan ook moet de topicstarter zich even in lezen in de gekozen oplossing

Eens.

[HyperBart]

brianb schreef op donderdag 2 april 2020 @ 10:44:
Thanks man! Nee, ik vat het ook zeker niet slecht op.
En ja, we lopen ''behoorlijk'' achter v.w.b. dit. Ik ben hier nu pas 4 jaar in dienst, maar toen ik kwam waren er nog 2003 servers, oude citrix omgeving (xenapp 6.5) nog steeds actief op dit moment, en veel verouderd.
Er heerste hier de gedachte waar ik behoorlijk kippenvel van krijg: "If it aint broke, dont fix it"
En achter die feiten hobbelen we nu aan...

Succes, cover your ass, kader de risico's en kosten naar je management en probeer het tij te keren, ooit komt dit nog wel eens bijten.

Ik ga denk ik de huidige applicatie server hier voor ombouwen, als de ADFS dan daarop ingericht is, kan ik hem downscalen qua performance, aangezien hij dan alleen nog maar deze rol vervult. Dan hoeft het niet op de Dc's.

Ffwd 2 jaar verder en je zit nog altijd met die server "ja want die deed nog iets met die applicatie en ergens draait er ook nog ADFS op". Lijkt me niet zoveel moeite om hier een apart OS voor op te zetten...? Je opvolger zal er blij mee zijn.

KnoxNL schreef op donderdag 2 april 2020 @ 12:58:
Ik zou in het verlengde van @Killah_Priest niet meer investeren in ADFS.

Het is een brakke oplossing,

Niet eens, het is op zich een prima oplossing in een mooi gescheiden model.

die je veel tijd en energie kost om in te richten en te beheren,

Dat dan wel weer, @brianb .

terwijl dit soort dingen prima via Azure AD kunnen.

ADFS is eigenlijk al niet meer van deze tijd, wij hebben het daarom +/- een half jaar geleden afgebouwd.

Als je meerdere federaties wil opzetten is het een prima oplossing, maar voor 1 applicatie vind ik het inderdaad wel een stevige overhead.

[ Voor 4% gewijzigd door HyperBart op 02-04-2020 15:29 ]

[brianb]

Ik denk dat gezien de huidige situatie en veelal gelijktijdige projecten Okta in dit geval de snelste/makkelijkste oplossing is.
Even gekeken en uiteindelijk doet die wel precies wat we moeten doen.
Nu maar even overleggen met de leverancier. Wellicht dat zij de kosten van Okta maar moeten betalen aangezien we het voor hun applicatie moeten gaan aanschaffen

Ik pas er namelijk voor als we meer richting Azure/Cloud willen, om nu 1 server uit te faseren (onprem) en vervolgens 2 vm's te moeten maken om dit voor elkaar te krijgen.

Thnx verder voor de vele aangeboden opties hier, top!

[ Voor 17% gewijzigd door brianb op 03-04-2020 11:52 ]

[Ivoknievel]

Okta cloud connect (dus een koppeling met je AD + 1 app (het ticket systeem in de cloud gekoppeld via SAML) is gratis (https://www.okta.com/occ/)

In principe een prima oplossing als je geen MFA toe willen passen. Wil je wel MFA dan zal je daar voor moeten betalen.

[brianb]

Ivoknievel schreef op vrijdag 3 april 2020 @ 13:06:
Okta cloud connect (dus een koppeling met je AD + 1 app (het ticket systeem in de cloud gekoppeld via SAML) is gratis (https://www.okta.com/occ/)

In principe een prima oplossing als je geen MFA toe willen passen. Wil je wel MFA dan zal je daar voor moeten betalen.

Geweldig, dankjewel hiervoor.
Zal het allemaal iets versnellen

[Maartendevreeze]

Als alternatief op Okta kun je ook kijken naar AzureAD. De gratis versie biedt tot 500.000 objecten en 10 SSO applicaties.
Je hebt dan enkel een Synchronisatieserver nodig. Meer info zie: https://azure.microsoft.c...details/active-directory/

Denk alleen wel goed na over aantal fundamentele inrichtingszaken, dan ben je klaar voor de toekomst. Mocht er in de toekomst besloten worden voor meer stappen richting de cloud (bijv. Office 365)

[brianb]

Maartendevreeze schreef op zondag 5 april 2020 @ 11:44:
Als alternatief op Okta kun je ook kijken naar AzureAD. De gratis versie biedt tot 500.000 objecten en 10 SSO applicaties.
Je hebt dan enkel een Synchronisatieserver nodig. Meer info zie: https://azure.microsoft.c...details/active-directory/

Denk alleen wel goed na over aantal fundamentele inrichtingszaken, dan ben je klaar voor de toekomst. Mocht er in de toekomst besloten worden voor meer stappen richting de cloud (bijv. Office 365)

hi, Office 365 staat in de planning. Gaat alleen heel moeizaam met veel legacy applicaties.
Ik ga dit bovenstaand advies zeker meenemen.

[iFap]

Ik zou even bij het begin beginnen. Je wilt namelijk geen ADFS, maar Single Sign On. Je kunt dat op twee manieren voor elkaar krijgen;

1. ADFS omgeving bouwen. Om dit redundant in te richten heb je al gauw 4 VM's nodig (2x ADFS, 2x WAP). Daarnaast moet je rekening houden met onderhoud (patchmanagement, certificaten op tijd vervangen etc.).

Of..

2. Je bespaart jezelf heel veel tijd en energie en je gaat aan de slag met Azure AD.

Je kan een SAML koppeling maken naar Azure AD met paar klikjes en je hebt Single Sign On. Voorwaarde is dat je wel je AD omgeving hebt gesynchroniseerd naar Azure AD met ADConnect. Dit staat los van O365 (Mail, SharePoint etc.).

Dit is in mijn ogen ook meteen een mooie eerste stap naar modern management wat ook weer makkelijker te verkopen is aan je managers. Je bespaart hiermee echt tijd + geld. ADFS is alleen maar achter de feiten aanlopen. Succes iig.

[technopeuter]

ADFS is dood, leve AzureAD

[Verwijderd]

technopeuter schreef op vrijdag 17 april 2020 @ 17:36:
ADFS is dood, leve AzureAD

Zal dan toch vooral gaan afhangen van de ondersteuning door applicaties. Federation is toch een stuk uitgebreider en veelzijdiger dan AAD.

Werkzaam in een grote enterprise hier, en federation is toch nog steeds de standaard. Zie niet veel applicaties passeren die daarnaast ook integratie met AAD verzorgen.

[brianb]

Inmiddels op alle tenants de licentie goed laten zetten (waar dit nog niet het geval was en er geen M365 licentie aanwezig was). Op 2 tenents moest ik de P1 licentie laten activeren.
Daarna de sAML geactiveerd met de gegevens van de leverencier. Juiste gebruikers hier aan toegekend en nu zijn we bijna zo ver!

Bedankt allen voor jullie tips.
Zijn nu wel wat kosten bij gekomen i.v.m. de benodigde licenties, maarja, wel weer een mooie voorbereiding op de ''toekomst'' (die bij velen al actief is )