December 19, 2019
Posted by on
Microsoft recommends using “Kerberos Authentication” template for Domain Controllers instead of older “Domain Controller” and “Domain Controller Authentication” templates https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-pki
we can easily do so creating a duplicate of “Kerberos Authentication” template and set up a superseding for templates issued based on older templates.
One of my Customers complained that when he did so, Active Directory Web Services (used, for example for remote Power Shell connect) started to log a Warning (Even Id 1400), regardless the fact the certificate has proper EKU and the server FQDN is included in subject name (as DNS name as it is described in the article) and in SAN.
Event Id: 1400
|Active Directory Web Services could not find a server certificate with the specified certificate name. A certificate is required to use SSL/TLS connections. To use SSL/TLS connections, verify that a valid server authentication certificate from a trusted Certificate Authority (CA) is installed on the machine.
It is important to note that by default “Kerberos Authentication” template has Subject name set to None as per RFC 3280, so he customized the template duplicate and put “DNS name” under “Subject name format”.
I created a new duplicate of the Kerberos Authentication template (Server 2003 Compatibility level!!!) and add a Common Name to the Subject Name field
after that I added the template to my CA and requested the template-based certificate from my Domain Controller. I removed the old certificatee to keep just one certificate in the Local machine store.
After after restart ADWS successfully recognized the certificate (Even Id 1401).
Note: Microsoft has an article saying the empty Subject name is fine from RFC point of view, but that can cause issues with third-party apps… It looks like not only with third party
March 16, 2017
Posted by on
One of my Customers asked about MFA for his on-prem Outlook. I offered several solutions, one of them – publish OWA site via Azure AD Application Proxy and pre-authenticate with Azure AD and MFA.
To be sure the configuration will work I built a Lab and tried to configure SSO for Internal Windows Authentication (IWA).
This configuration requires I configure Kerberos Constrained Delegation (KCD) in Active Directory and configure Delegation in Properties of a machine where I have my Azure AD Proxy Connector installed.
Everything looked easy on paper byt when I tried it in Active Directory Users and Computer MMC I received nice error: “The server is unwilling to proceed the request”
After unsuccessful googling I opened a case with Microsoft – that was a brand new domain, just couple of servers and I definitely expected everything working out of the box.
After couple of days of troubleshooting the only solution MS suggested was using an Active Directory Administrative Center instead of MMC. Even with that the first attempt failed with “Unknown error”. After the Center was restarted we could finally configure the delegation. No root cause found.