Sandro Reiter

vCard und IT-Blog

Neueste Beiträge

Kategorien

Archive

ADFS: Certificate-Binding wird nicht korrekt ersetzt

Neben der klassischen Kombination aus Benutzername und Passwort zur Authentifizierung beherrschen die Active Directory Federation Services (ADFS) auch die Anmeldung per Nutzerzertifikat.

Hierzu wird von Microsoft empfohlen, dem ADFS Service-Communications-Certificate den alternativen DNS-Namen (SAN) certauth.adfs.meinedomäne.tld hinzuzufügen.

Während der ADFS-Konfiguration wird dieser Endpunkt entsprechend erstellt und das Zertifikat auf Port 443 gebunden.

Enthält das Zertifikat diesen SAN nicht, wird die zertifikatsbasierte Authentifizierung auf Port 49443 und den Service-Namen (adfs.meinedomäne.tld) gebunden.

 

So weit, so gut:

In einem Kundenszenario hatte ich nun den Fall, dass das Service-Communications-Zertifikat ersetzt werden musste. Gesagt, getan:
Zertifikat angefordert, PFX importiert und per PowerShell ersetzt

#replace adfs sts certificate, prequisite: certificate pfx has to be installed
Set-AdfsSslCertificate -Thumbprint "FC85DDB0FC58E63D8CB52654F22E4BE7900FE349"

Auf den Web Application Proxy (WAP) – Maschinen habe ich die Schritte zur Ersetzung des Zertifikats ebenfalls durchgeführt.

Die Umgebung lief bis zu dem Tage, als das alte Zertifikat abgelaufen ist, fehlerfrei. An dem Tag, nach dem das alte Zertifikat ungültig wurde, war der ADFS von extern nicht mehr erreichbar.

 

Der WAP meldete, das der ADFS-Services “unavailable” wäre mit dem Fehler-Code “503”. Eine Re-Konfiguration des WAP endete mit dem Fehler:

“An error occurred while attempting to establish a trust relationship with the Federation Server.

Nach diversen Netzwerk-/Firewall-Tests blieb die Vermutung das es am ADFS selbst liegt…

Eine Überprüfung der Bindings mit

#show adfs ssl bindings
Get-AdfsSslCertificate

bestätigte den Verdacht

HostName                           PortNumber  CertificateHash
--------                           ----------  ---------------
localhost                             443      FC85DDB0FC58E63D8CB52654F22E4BE7900FE349
adfs.meinedomäne.tld                  443      FC85DDB0FC58E63D8CB52654F22E4BE7900FE349
adfs.meinedomäne.tld                  49443    FC85DDB0FC58E63D8CB52654F22E4BE7900FE349
certauth.adfs.meinedomäne.tld         443      3F65896B1E2102515FC7942BD1FC6D9F3603C04A

 

Das Zertifikat für die zertifikatsbasierte Authentifizierung wurde nicht aktualisiert.
Der WAP lief nun in den Fehler, auf ein abgelaufenes Zertifikat zu treffen.

 

Auf dem primären ADFS-Node muss also zusätzlich noch das certauth-Zertifikat ersetzt werden. Das gelingt per PowerShell wie folgt:

#replace adfs sts alternate certificate, prequisite: certificate pfx has to be installed
Set-AdfsAlternateTlsClientBinding -Thumbprint "FC85DDB0FC58E63D8CB52654F22E4BE7900FE349"

Die anschließende erneute Überprüfung der Bindings mit

#show adfs ssl bindings
Get-AdfsSslCertificate

bestätigt die Änderung.

Alle ADFS-Domains nutzen nun das neue, gültige Zertifikat.
Jetzt noch die Web Application Proxies re-konfigurieren, was nun fehlerfrei durchlaufen sollte. Check.

Die ADFS-Testseite (https://adfs.meinedomäne.tld/adfs/ls/IdpInitiatedSignon.aspx) war von extern wieder aufrufbar. Die Anmeldung der Nutzer war ebenso wieder möglich.

 

Warum dieses Verhalten beim Ersetzen des Zertifikats auftritt, erschließt sich mir nicht. Schließlich wird das Zertifikat bei der initialen ADFS-Einrichtung auch explizit auf diese Sub-Domain gebunden, also warum dann das neue Cert (mit den gleichen SANs) nicht auch für die zertifikatsbasierte Authentifizierung aktualisieren? Feature oder Bug?

Published by Sandro on | Permalink

Office 365: Neue Möglichkeit zur Zusammenarbeit

Heute habe ich durch Zufall eine spannende Option in den Azure AD Organisationseinstellungen entdeckt:

Auch wenn derzeit noch Preview dran steht, finde ich die Funktion enorm nützlich. Ich weiß gar nicht, wie viele der durch mich betreuten Kunden schon danach gefragt haben.

 

Aber was hat es mit dieser Einstellung auf sich?

Auch wenn Microsoft fleißig daran arbeitet, gibt es auch in 2019 immer noch Personen die keinen Microsoft Account oder ein Office 365 / Azure AD Konto besitzen (wollen/können/dürfen).

Oftmals ist die IT in großen Konzernen sehr restriktiv und so dürfen bspw. keine privaten Accounts genutzt werden und der Einsatz von OneDrive ist frühstens in 2054 geplant.

Mit OTP (one time password) als Alternative zu klassischen Einladungen für die Zusammenarbeit in Office 365 ist auch denjenigen geholfen, die zu dem oben beschriebenen Nutzerkreis gehören.

Ein einmaliger Code in Kombination mit der eigenen E-Mail-Adresse dient als Authentifizierungsmethode um auf Inhalte zuzugreifen – Gültigkeit eines OTP: 24 Stunden.

 

Und so sieht es, anhand eines OneDrive Sharing-Prozesses, für die Benutzer aus:

Die Datei oder der Ordner wird über das Teilen-Menü mit einem externen Benutzer geteilt.

Der teilende Benutzer sendet eine Einladung zur Zusammenarbeit an die angegebene E-Mail-Adresse. 

Microsoft prüft im Hintergrund ob zu dem Konto ein Microsoft-/Azure AD-Account existiert. Wenn dies nicht der Fall ist, wird der Eingeladene auf das OTP-Verfahren umgeleitet. Der eingeladene Benutzer gibt zur Verifizierung seine E-Mail-Adresse und den Einmalcode (OTP), welcher gesondert per E-Mail versendet wird, zur Authentifizierung ein.

Nach erfolgreicher Authentifizierung kann nun endlich kollaboriert werden.

Der Besitzer bzw. Absender der Datei-/Ordnerfreigabe bekommt außerdem eine Benachrichtigung darüber, das die eingeladene Person den OneDrive-Link geöffnet hat.

 

 

Microsoft zeigt damit wieder, das Feedback gehört und berücksichtigt wird. Ich bin gespannt was sich bis zur finalen Veröffentlichung hier noch tut.

Published by Sandro on | Permalink

Azure AD: UPN eines Hybrid-Users ändern

Als wir vor Kurzem einen neuen Kollegen eingestellt haben, wünschte dieser sich einen kürzeren Anmeldenamen (UPN) für Office 365 und Co.
Da ich natürlich vorbildlich bereits vor seinem Dienstantritt das Active Directory-Konto erstellt habe, änderte ich einfach den UPN am AD-Objekt und auch die neue Adresse im ProxyAdresses-Attribut wurde veröffentlicht und als primär festgelegt.

Als nach mehrfachen automatischen AAD Connect Synchronisationen der kosmetische Eingriff noch nicht geglückt war, habe ich eine manuelle Synchronisation angestoßen…

Start-ADSyncSyncCycle -PolicyType Delta

… allerdings ebenfalls ohne Erfolg.

 

Ich musste ein wenig in meinem Gedächtnis kramen – denn genau diese Änderung habe ich bereits an meinem eigenen Benutzerkonto durchgeführt – Déjà-vu! Mir fiel wieder ein, was ich schon mal vergessen habe.

Es ist natürlich richtig und wichtig den UPN und die neue Mail-Adresse im OnPremises AD zu ändern. Wenn das Konto aber bereits synchronisiert ist und in Azure AD angelegt, muss der UPN auch nochmal auf Azure AD-Seite geändert werden. Das gelingt ganz einfach wie folgt:

#connect to Azure AD tenant
Connect-AzureAD

#change UPN to default tenant-domain
Set-AzureADUser -ObjectId user@contoso.com -UserPrincipalName user@contoso.onmicrosoft.com

#set the UPN like the UPN in OnPrem AD
Set-AzureADUser -ObjectId user@contoso.onmicrosoft.com -UserPrincipalName mrright@contoso.com

 

Nachdem das nun erledigt ist, gilt der neue UPN in beiden IDPs – sowohl im Active Directory als auch Azure AD.

 

Famous last words: Wenn der UPN geändert wird, ändert sich auch die SIP-Adresse des jeweiligen Benutzers. Diese Adresse wird u.a. im Skype for Business-Verzeichnisdienst verwendet. Das wiederum hat die Folge, das bereits bestehende Kontakte den Benutzer mit neuem UPN erneut zur Kontaktliste hinzufügen müssen.

Published by Sandro on | Permalink