5ain7 ga11 . CH || i7-l3ak5. CH || g07r007.CH

Wenn man versucht, bei einem Exchange 2010/2013 den POP3 und IMAP Services ein Wildcard Cert zuzuweisen, kommt folgende Meldung:

<Enable-ExchangeCertificate -Thumbprint XXXXXXXXXXXXXXXX -Services POP
WARNING: This certificate with thumbprint XXXXXXXXXXXXXXXXXXXXXX  and subject '*.example.com' cannot used for POP SSL/TLS connections because the subject is not a Fully Qualified Domain Name (FQDN). Use command Set-POPSettings to set X509CertificateName to the FQDN of the service.>

Das gleiche ist bei IMAP…

Der FQDN der X509 Certs muss dazu angepasst werden.

<Set-POPSettings -X509CertificateName mail.domain.ch>

<Set-IMAPSettings -X509CertificateName mail.domain.ch>

Danach noch die Services restarten.

<Restart-service MSExchangePOP3>
<Restart-service MSExchangeIMAP4>

Die Dienste lassen sich jetzt zuweisen.

Ich hatte das Problem, dass sich die User via Outlook Webapp (published via ADFS & WAP) nicht formularbasiert anmelden konnten. EAS und Konsorten funktionierten einwandfrei.

Nach dem Login auf dem neuen ADFS Page, passierte einfach nichts…

Auf dem WAP Server sieht man, dass ein Kerberos Ticket angefordert wird, der ADFS Server aber kein Ticket zurücksenden kann. Die Logs auf dem WAP Server zeigten folgendes:

EVENT ID 12027, Username and Password wrong (0x8007052e).

Auf dem ADFS Server sieht man folgendes:

<364:

Encountered error during federation passive request.
Additional Data
Protocol Name:
Relying Party:
Exception details:
Microsoft.IdentityServer.Web.InvalidScopeException: 06a7aa66-3aad-e311-80c1-005056983900

 at Microsoft.IdentityServer.Web.Protocols.MSISHttp.MSISHttpProtocolHandler.ValidateSignInContext(MSISHttpSignInRequestContext msisContext, WrappedHttpListenerRequest request)

 at Microsoft.IdentityServer.Web.Protocols.MSISHttp.MSISHttpProtocolHandler.CreateProtocolContext(WrappedHttpListenerRequest request)

 at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetProtocolHandler(WrappedHttpListenerRequest request, ProtocolContext& protocolContext, PassiveProtocolHandler& protocolHandler)

 at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)
>

Das Problem lag daran, dass der WAP-Server keine Berechtigung hatte Kerberos-Sicherheitstokens anzufordern. 

Nachdem ich den WAP Server in die Gruppe <Windows Authorization Access Group>
hinzugefügt hatte, funktionierte es nach dem Reboot einwandfrei.

 

Windows Authorization Access Group

In the user account in Active Directory there is a computed token. This is a computed version of the same security token that is created when a user logs in. You only need to add users to this group for special software that requires this access