none
ADFS mit *.local Domain RRS feed

  • Frage

  • Hallo zusammen,

    ist es möglich eine AD FS Umgebung (Server 2012 R2 & Funktionsebene 2012) zur Anbindung externer Services wie Office 365 mit einer *.local Domäne ohne krude Hacks zu bauen oder gibt es da Probleme?


    Freundliche Grüße
    Sandro

    MCSA: Windows Server 2012
    Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)

    XING: Zum Profil
    LinkedIn: Zum Profil
    Facebook: Zum Profil


    • Bearbeitet SandroReiter Donnerstag, 29. September 2016 09:47
    Donnerstag, 29. September 2016 08:54

Alle Antworten

  • Hi,
     
    Am 29.09.2016 um 10:54 schrieb SandroReiter:
    > ist es möglich eine AD FS Umgebung (Server 2012 R2 & Funktionsebene
    > 2012) zur Anbindung externer Services wie Office 365 mit einer *.local
    > Domäne ohne krude Hacks zu bauen oder gibt es da Probleme?
     
    Warum sollte es da Fehler geben?
     
    Tschö
    Mark
     
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Donnerstag, 29. September 2016 12:34
  • Warum sollte es da Fehler geben?

    Eine nicht routbare TLD könnte evtl. bei externen Services Probleme verursachen - dachte ich ;)
    https://support.office.com/de-de/article/Vorbereiten-einer-nicht-routbaren-Dom%25C3%25A4ne-wie-z-B-der-Dom%25C3%25A4ne-local-f%25C3%25BCr-die-Verzeichnissynchronisierung-e7968303-c234-46c4-b8b0-b5c93c6d57a7?ui=de-DE&rs=de-DE&ad=DE&fromAR=1

    Wenn es nichts zu befürchten gibt, dann ist es umso besser! :)


    Freundliche Grüße
    Sandro

    MCSA: Windows Server 2012
    Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)

    XING: Zum Profil
    LinkedIn: Zum Profil
    Facebook: Zum Profil


    • Bearbeitet SandroReiter Donnerstag, 29. September 2016 12:38
    Donnerstag, 29. September 2016 12:36
  • > Eine nicht routbare TLD könnte evtl. bei externen Services Probleme
    > verursachen - dachte ich ;)
     
    Nicht "könnte", sondern "wird" - das muß von außen erreichbar sein, Du
    brauchst also eine öffentliche IP und einen öffentlichen DNS-Record.
     
    Donnerstag, 29. September 2016 13:04
  • Ja, aber doch nur für die ADFS-Farm, nicht für die Domäne per se, oder? Und ADFS löst dann intern gegen ADDS die Usernamen auf.

    Oder?


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 29. September 2016 14:14
  • > Ja, aber doch nur für die ADFS-Farm, nicht für die Domäne per se, oder?
    > Und ADFS löst dann intern gegen ADDS die Usernamen auf.
     
    Gute Frage - ich sag mal nix mehr, der wo das bei uns implementiert hat,
    ist heut nimmer da :)
     
    Donnerstag, 29. September 2016 15:53
  • Hi,
     
    Am 29.09.2016 um 14:36 schrieb SandroReiter:
    > Eine nicht routbare TLD könnte evtl. bei externen Services Probleme
    > verursachen - dachte ich ;)
     
    Ich bin sicherlich alles andere als der richtige Ansprechpartner für
    Azure, aber ich würde tippen, daß 85-95% aller ADs nicht routbar sind?
     
    Stell dir mal vor MS würde alle diese ADs als potentielle Kunden
    verlieren ... No way.
     
    Bei MS geht es nur ums Geld. Die sind nicht nett, die machen das nicht
    weil sie Technik geil finden. Die wollen Geld verdienen, .local wird
    gehen, genauso, wie jede andere Domäne auch.
     
    ... da lehne ich mich jetzt mal weit aus dem Fenster und warte auf
    Absturz :-D
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Donnerstag, 29. September 2016 16:26
  • Nö, wieso ;-) Alles richtig.

    ABER: Wenn tatsächlich O365 angebunden werden soll, tut man sich einen Riesengefallen, wenn man UPN an die primäre e-Mail-Adresse angleicht, s. auch hier: http://blogs.perficient.com/microsoft/2015/07/office-365-why-your-upn-should-match-your-primary-smtp-address/

    Für die Funktion von ADFS per se ist es aber nicht notwendig.


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 29. September 2016 16:36
  • Also, ich führe mal etwas mehr aus:

    Umgebung: Windows Server 2012 R2 mit lokalen AD DS (DFL 2012) nix Azure ;)
    Domäne: meinefirma.local (keine Subdomains)
    PKI: Offline Standalone RootCA & Online Enterprise SubCA

    Zielstellung: Ermöglichen von SSO bei externen Services wie Office 365, Exchange Online, perdoo, InVision, umantis etc. (was auch immer noch an Diensten dazukommt) mittels der im lokalen AD DS hinterlegten Credentials.

    Dabei soll der IIS und Federation Proxy in der DMZ und der Federation Server im LAN stehen.

    Die grundlegende Frage: Kann uns das *.local hier in irgendeiner Weise einen Knüppel in die Beine hauen?

    Allgemeiner Hinweis zu meinen blöden Fragen: Meine AD FS Kenntnisse belaufen sich auf "einmal in der 70-411/412 gemacht"


    Freundliche Grüße
    Sandro

    MCSA: Windows Server 2012
    Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)

    XING: Zum Profil
    LinkedIn: Zum Profil
    Facebook: Zum Profil



    • Bearbeitet SandroReiter Donnerstag, 29. September 2016 16:48
    Donnerstag, 29. September 2016 16:45
  • Moin,

    ich frag mal ganz ketzerisch zurück: Und was, wenn jetzt jemand (fundiert und begründet) sagt "Jo, wirst mit Cloud Service XY Probleme kriegen". Migrierst Du dann die ganze AD? Welchen Namen nimmst Du dann? Öffentlichen? Privaten, nur mit einer anderen TLD als .local?


    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 29. September 2016 17:38
  • Wenn es 1 Service betrifft - ok, dann wird der eben weg gelassen. Betrifft das jetzt den Großteil oder gar alle muss ich grundlegend neu über die Sache nachdenken ggf wie Du schon sagst mit neuer TLD.

    Mich nervt es ehrlich auch, das einmal zu schnell nachgegeben (Entscheidung der TLD) so gravierende Folgen hat/haben kann. Jetzt weiß ich auch das *.local u.U. nicht die klügste Lösung war - und die Frage nicht ist ob, sondern wann das Probleme bereitet. Aber gut, das Kind liegt tief im Brunnen und ich muss jetzt damit arbeiten und soviel wie möglich damit umsetzen :/

    Also bitte einfach nicht ketzerisch fragen :D


    Freundliche Grüße
    Sandro

    MCSA: Windows Server 2012
    Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)

    XING: Zum Profil
    LinkedIn: Zum Profil
    Facebook: Zum Profil

    Donnerstag, 29. September 2016 17:46
  • Nun, aus Deinem Brunner gibt es ja vielleicht einen schnellen Ausweg. In der Welt von ADFS ist die stabilste Währung eigentlich der UPN. Ist es für Dich möglich, für die User, die von diesen externen Services betroffen sein werden, nur den UPN zu ändern, und zwar auf die e-Mail-Adresse? Wenn das geht, würde ich sagen, dass es für die Integration von Cloud-Diensten vollkommen gleich ist, wie die DNS-Suffixe der ganzen internen Server aussehen, denn nur für diese bleibt dann .local aktiv.

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 29. September 2016 18:04
  • Am 29.09.2016 um 18:26 schrieb Mark Heitbrink [MVP]:
    > ... da lehne ich mich jetzt mal weit aus dem Fenster und warte auf
    > Absturz :-D
     
    Ich lehne mich wieder zurück :-)
     
    Das ist ja einfach. Ich wusste sie wollen Geld verdienen.
    ADMT ist nicht notwendig. war eh klar :-P
     
    You can fix this issue [...] by adding one or more UPN suffixes.
     
    Mit anderen Worten: Mach deine Ext. Mailadresse zum Anmeldenamen und
    fertig die Laube.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Donnerstag, 29. September 2016 18:05
  • Hi,
     
    Am 29.09.2016 um 19:46 schrieb SandroReiter:
    > [...] Jetzt weiß
    > ich auch das *.local u.U. nicht die klügste Lösung war
     
    Es gibt genügend Argumente gegen eine "routbare" Domäne.
    Ob du nun .local oder .zzz genommen hast ist jetzt ziemlich egal.
     
    Du hast in jeder Form der Namensauflösung ein Namensauflösungsproblem,
    entweder von der einen Richtung oder aus der anderen.
    Oder anderes ausgedrückt in der einen Variante ist Handarbeit im DNS und
    in der anderen auch ... entweder trägst du externe IP Adressen für
    "interne" A-Records ein oder interne IP Adressen für "externe" A Records.
     
    Da ist weder ein Kind in den Brunnen gefallen, noch ist es "unrettbar".
     
    Wie gesagt: Denk immer dran, es geht um Geld. MS will das verkaufen, die
    machen "alles" möglich, damit Cloud Vollgas ohne Bremse verbimmelt
    werden kann
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Donnerstag, 29. September 2016 18:13
  • Ob du nun .local oder .zzz genommen hast ist jetzt ziemlich egal.

    ... es sei denn, Du hast MacOS X im Einsatz ;-) Ich habe gehört, das Issue, das wir schon mal hatten, ist wieder in abgewandelter Form aufgetreten...

    Evgenij Smirnov

    msg services ag, Berlin -> http://www.msg-services.de
    my personal blog (mostly German) -> http://it-pro-berlin.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com

    In theory, there is no difference between theory and practice. In practice, there is.

    Donnerstag, 29. September 2016 18:20
  •  
    Ich lehne mich wieder zurück :-)

    Danke für den Link, die deutsche Version davon habe ich aber bereits hier gepostet ;)


    Freundliche Grüße
    Sandro

    MCSA: Windows Server 2012
    Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)

    XING: Zum Profil
    LinkedIn: Zum Profil
    Facebook: Zum Profil

    Freitag, 30. September 2016 04:56

  • ... es sei denn, Du hast MacOS X im Einsatz ;-)

    Haben wir ;)

    Es gibt genügend Probleme damit :/


    Freundliche Grüße
    Sandro

    MCSA: Windows Server 2012
    Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)

    XING: Zum Profil
    LinkedIn: Zum Profil
    Facebook: Zum Profil

    Freitag, 30. September 2016 04:59
  •  Ist es für Dich möglich, für die User, die von diesen externen Services betroffen sein werden, nur den UPN zu ändern, und zwar auf die e-Mail-Adresse?

    Als Du das mit dem Office 365 und UPN erwähnt hast hab ich mich schon in die Spur gemacht. Ich werde das Thema direkt heute angehen, da ich denke mit einem "korrekten" UPN neben dem SSO noch so  1-2 nice2have Sachen umgesetzt werden können.

    Ich hab mich mal (damals) ganz kurz mit UPN beschäftigt, festgestellt das ich mich damit nicht am Client (zumindest nicht default) anmelden kann und dann wieder verworfen. Wie ich nun feststelle hätte ich da mal lieber dran bleiben sollen, da dem UPN doch mehr Beachtung geschenkt werden sollte als ich es bis jetzt Tat :)


    Freundliche Grüße
    Sandro

    MCSA: Windows Server 2012
    Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)

    XING: Zum Profil
    LinkedIn: Zum Profil
    Facebook: Zum Profil

    Freitag, 30. September 2016 05:04
  • Ich werde das Thema direkt heute angehen, da ich denke mit einem "korrekten" UPN neben dem SSO noch so  1-2 nice2have Sachen umgesetzt werden können.

    So, ich habe das E-Mail-Suffix dem AD hinzugefügt und den UPN bei allen Usern aktualisiert

    Get-ADUser -Filter * -SearchBase 'DC=FIRMA,DC=local' -Properties userPrincipalName | foreach { Set-ADUser $_ -UserPrincipalName "$($_.samaccountname)@new.suffix"}

    Die 1. nice2have Sache habe ich bereits getestet, bei der Einrichtung von Outlook gegenüber dem Exchange Online steht nun im Login bereits der richtige Anmeldename drin.

    Mit altem UPN war das username@firma.local, was natürlich nicht ging und man musste es immer händisch in firma.com abändern. Jetzt mit korrektem UPN steht username@firma.com schon drin und es wird nur noch das Passwort benötigt - kleine aber feine Sache :)

    Somit sollte dem Aufbau von AD FS bezüglich der TLD Wahl nichts mehr im Wege stehen oder gibt es noch weitere Tipps/Hinweise? ;)


    Freundliche Grüße
    Sandro

    MCSA: Windows Server 2012
    Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)

    XING: Zum Profil
    LinkedIn: Zum Profil
    Facebook: Zum Profil


    Freitag, 30. September 2016 06:17
  • Hi,
     
    Am 29.09.2016 um 20:20 schrieb Evgenij Smirnov:
    > ... es sei denn, Du hast MacOS X im Einsatz ;-)
     
    Das Problem habe ich ehrlich gesagt nie verstanden. Kann mir das mal
    jemand erklären?
     
    Der Mac hängt halt ".local" an den Hostnamen an, um einen gültigen FQDN
    zu erzeugen.
     
    Solange der MAC jetzt nicht so heisst, wie die interne Firmendomäne,
    sollte er mit dem AD DNS, den er verwendet nicht kollidieren.
     
    Er kriegt ein DNS Suffix oder auch mehrere, er hat den DNS, wieso spielt
    er nicht nach IP Regeln? Den "Broadcast" mit eigener Endung dürfte er
    garnicht machen, solange der DHCP auf "Register DNS" für Clients macht,
    die es nicht unterstützen, bzw. der Mac sich ordentlich im DNS
    registriert ... Ich habe keine Macs, ich kann nicht mitreden.
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Freitag, 30. September 2016 09:58
  • Am 30.09.2016 um 06:56 schrieb SandroReiter:
    > Danke für den Link, die deutsche Version davon habe ich aber bereits
    > hier gepostet ;)
     
    Ups, habe ich wohl übersehen ...
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    Freitag, 30. September 2016 09:58
  • Am 29.09.2016 schrieb SandroReiter:
    Hi,
     > Zielstellung: Ermöglichen von SSO bei externen Services wie Office 365, Exchange Online, perdoo, InVision, umantis etc. (was auch immer noch an Diensten dazukommt) mittels der im lokalen AD DS hinterlegten Credentials.

    Ja, das dürfte für 99,9% der ADFS Nutzer der Grund sein. Und du kannst wie Mark schon erwähnte davon ausgehen, dass es genug nicht routbare AD Domain Namen gibt. Für SSO brauchst du einen öffentlichen Zugriffspunkt wie sso.deinepublicdomain.tld und ein entsprechendes Zertifikat und logischerweise eine externe IP mit Port 443 Nutzung. Der Rest wird dann entsprechend konfiguriert.

    Die grundlegende Frage: Kann uns das *.local hier in irgendeiner Weise einen Knüppel in die Beine hauen?

    Nein.

    Allgemeiner Hinweis zu meinen blöden Fragen: Meine AD FS Kenntnisse belaufen sich auf "einmal in der 70-411/412 gemacht"

    Ruf doch Office 365 MS an und frag sie. ;)

    Bye
    Norbert


    Dilbert's words of wisdom #04:
    There are very few personal problems that cannot be solved by a suitable application of high explosives.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Freitag, 30. September 2016 22:05