___________________________________________________________________________________________________________________________
 every ADFS deployment I’ve been a part of, most of the conversations and planning revolve around certificates so I figured we should take some time to talk about this. ADFS relies heavily on public/private key certificate so if you’re not already familiar certificates, deploying ADFS will quickly get you re-acquainted. forget the basics about public/private certificate signing and encryption. Like most things, certificates are mostly 90% planning and 10% execution.
In 95% of ADFS deployments, it will require three certificates to be properly installed:
- SSL certificate
- Token Signing Certificate
- Token “Decryption” Certificate
There may be times where you want to install a fourth certificate, separate from the SSL certificate, although in most cases these certificates are one in the same:
- Service-Communications Certificate
You can use the same certificate for all three of these purposes, use separate certificates for each purpose, the choice is really yours. You can acquire them the certificates container, doesn’t mean encryption of tokens is actually being performed. There is A LOT of confusion because of how the ADFS management console displays the self-signed certificates. It says Token-decrypting above the certificate but the CN on the certificate says ADFS Encryption..
Digital Decryption
I know what you’re thinking – We just covered digital encryption so why are we covering it in the reverse – decryption. Because in this scenario, rather than our ADFS server sending tokens to a SaaS application, we’re receiving tokens from a partner Identity Provider  will use the private key of your token signing certificate and optionally digitally sign the SAML Sign-In request when the request is sent over to our ADFS server.
Why would you/they want to do this? Well, for the same reasons we digitally sign anything – To ensure the SAML request doesn’t get modified somehow. There typically isn’t anything really important in the SAML request but there are times when the SaaS application owner or you may want to enforce a certain authentication type by hardcoding it into the SAML request. If they also digitally sign the SAML request, they can ensure no one modifies the request and bypass about the certificates required for ADFS. Once you answer these questions, they myriad options for certificates that I mentioned above will become clear.
1.) Will external customers, partners, or non-domain-joined devices being using your ADFS service in some capacity?
Why?
Why is this important: This leads to two important requirements:
- whether you’ll need an ADFS Proxy/WAP server and corresponding SSL certificates.
- since this name is not a publically routable DNS name. If you plan to publish an ADFS Proxy/WAP server to the internet, make sure that the name of the certificate is a publically routable DNS namespace.
3.) Will you be using Outlook or other thick client applications with O365 for Exchange Online?
Why is this important: If you remember from my first blog on ADFS back in August 2014, when thick clients like Outlook.
Why?
Why is this important: When you use the self-signed certificates for token signing and decryption, the private keys are stored in Active Directory in the following container:
CN=ADFS,CN=Microsoft,CN=Program Data,DC=domain,DC=com
Consequently, for the ADFS installation to install the private keys into this location, you must be a domain admin to install ADFS or have the appropriate rights assigned to this container.
6.) Do you have a policy about using Next Generation (NGen) certificates?
Why?
Why?
Why. While you’re at it, run a quick check to ensure the SPN isn’t already in use in the enterprise:
Get-ADObject -filter 'ServicePrincipalName -eq "Host/sts.domain.com"'?
Why Subject Alternative Name (SAN) on the SSL certificate contains the same ADFS service name.
10.) Do you have any policy that dictates the use of wildcard SSL certificates?
Why is this important: While wild card SSL certificates are supported by all versions of ADFS, make sure that it complies with your corporate policy. I don’t typically recommend the use of wildcards certificate on the ADFS Proxy/WAP servers. If you have many UPN’s within the enterprise and plan to do device registration/workplace join, you may want to consider a wildcard certificate.
11.) Are you required to use a physical, virtual, or networked HSM for storing the certificates?
Why is this important: HSM devices are supported with ADFS but may cause performance issues since the private keys are stored on these other devices so make sure to test ADFS performance before going live.
12.) Do your monitoring devices support Server Name Indication (SNI)?
Why is this important: If you monitoring devices don’t support SNI and you’re using ADFS 2012 R2, then you will need to install August 2014 Windows Update rollup, so that you won’t need to modify the Subject Alternative Name (SAN) of all the ADFS certificates to ensure your HTTP probes work properly:
13.) If you are onboarding SaaS applications to your ADFS infrastructure, will the SaaS application want the SAML token encrypted and if so, do you know whether their encryption certificate is publically trusted?
Why is this important: If token encryption needs to Identity Provider (IDP) will be sending you SAML tokens, do you know whether their token signing certificate is publically issued?
Why?
Why naming. It really doesn’t matter beyond the considerations above.
ADFS Proxy/WAP Server SSL Certificate Guidelines
While you could install the same SSL certificate on all of the ADFS Proxy/WAP servers as you did your ADF servers, I typically don’t recommend it. The ADFS Proxy/WAP servers are supposed to be installed into the DMZ and not domain joined
Due to security concerns with the ADFS Proxy/WAP server, I typically recommend that customers install a separate SSL certificate on their ADFS Proxy/WAP servers. The only thing you must ensure is that the Common Name (CN) or Subject Alternative Name (SAN) contain the same ADFS service name. You can install the same SSL certificate on a relying party application.
It’s also OK to get a Token Signing Certificate from your internal CA
You can also get a certificate from your internal CA and the Enhanced Key Usage (EKU) on the certificate does not them the following to update the configuration in O365: subset Identity Providers (IDP) sending you tokens that require encryption, this certificate will rarely be used.
It’s also OK to get the Token Decryption Certificate from your internal CA
You can also get a certificate from your internal CA and the Enhanced Key Usage (EKU) on the certificate does not matter.
But be willing to get a Publically Trusted Token Decryption Certificate
If you have partner IDP’s sending you tokens that require encryption and they plan to also perform certificate revocation checking on the public portion, what my middle name is? There is a clue in the blog. +10 points for the first one to figure it out.
Next Blog in Series:
Join the conversationAdd Comment
Jeremy Hagan,
There is nothing stopping you from using the same certificate, certainly no technology reasons. I personally like using separate certificates because it gives me more granularity to dictate different settings, if I need to, plus like you mentioned, if I’m every
forced to change one, I don’t have to worry about the other certificates.
While it may cost more to get different certificates (if using public trusted), it really isn’t that more complex, and it gives you some more granularity and some level of control of each certificate without having to worry about the other certificates, especially
when it’s time to update the TS cert for RP’s. 🙂 While I’m personally very cost-conscious, spending a few hundred bucks more for most enterprise customers is a rounding error at best. For my personal lab, I usually use all self-signed certificates so I can
bring stuff up and down quickly.. 🙂 Some infosec departments may also have some policies around certificate governance and usage.
Jason,
Ironically, I published a blog earlier this week exactly on this topic. Hopefully it helps:
Great article Homer!
"Decryption"
Thanks a lot
the whole series of articles were very very helpful
create article, thanks!
Thanks for the article. It’s also good for your readers to note that the auto rollover for the token-signing and token-decrypting certs can happen much earlier than the expiration of the cert, based on the CertificateGenerationThreshold and CertificatePromotionThreshold
properties. Before I could extend my threshold and set a date with application owners of a planned switch, my new certs had auto-generated and were promoted to primary, putting the app owners into a panic until I gave them the new cert. This is for 2.0, but
it covers the properties:
"?"
For accuracy, I would change:
"ADFS requires three certificates to be properly installed.
•SSL certificate
•Token Signing Certificate
•Token “Decryption” Certificate"
by adding
•Service Communication Certificate
From here: ""
AD FS effectively uses 4 certs, and it’s my understanding that the SSL and Service Communication certificates do not have to necessarily be the same. Correct?
Hello David, would it be possible for the future to explain more about SAML artifact resolution? I’m not entirely getting the mechanics (how it works under the hood) and when/why a service provider would want to implement it. Thanks!
Great article. It is the only place I found that said why you need to use a common SSL certificate.
Can you please expand on the reason why not to use the SSL certificate as the token-signing or decryption certificates? The main reason I can think of is that if you change your SSL certificate and you have used the same certificate for all three that you’d
need to notify your relying parties of the new certificate.
Do you have any recommendation for whether or not to use the same certificate for the token signing and decryption?
Re: Using a single certificate. I noticed that sts.cloudready.ms is using the same Go Daddy issued SSL certificate as the token signing and decryption certificate against the recommendation in the article. Matches the thumbprint referenced in the article.
Regarding " 9.) Do you have any policy about using the same SSL certificates on the ADFS servers as you do the public-facing ADFS proxy/WAP servers?"
According to Technet ():
“It is strongly recommended to use the same SSL certificate for the Web Application Proxy. This is however required to be the same when supporting Windows Integrated Authentication endpoints through the Web Application Proxy and when Extended Protection Authentication
is turned on (default setting).”"
You might want to mention this.
These blog posts have been very informative. I am eagerly waiting for the next. Hopefully "conversations we need to have with application owners that want to onboard their applications to ADFS"
Disclaimer: Some concepts have been simplified until I’m ready to cover them in more detail. This is
Great article!!! Happy I discovered it! You addressed so many questions I had. Thank you so much. Do you have by any chance step-by-step to configure on premises adfs and wap/adfs proxy to work with external partners claim aware application to use SSO.
Thank you in advance
Madina,
I can’t cover onboarding every application to ADFS but I did write any article back in March the covers the fundamentals to onboarding many applications to ADFS:
Does this partner have ADFS or another Identity product or would you be federated directly with the application? If the latter, the above article should help. Let me know. Thanks, Dave
Dave thank you for prompt reply. The partner is they support saml 2.0..we need to implement SSO so our user will login to using AD credentials. Hope it cleared
Madina,
I know its a long read but the article I suggested in my earlier comment should help. At a minimum, they will need the following from you:
Your ADFS Identifier:
Public portion of your token signing certificate
Your ADFS Logon URL:
At a minimum, you will need the following from them:
Their identifier, they call this the Service Provider issuer
What claims they want sent back – email address, UPN, etc
Their token endpoint which is a URL that your tokens should be submitted back to on their side
From your ADFS console, you would need to create a new relying party trust and do the following:
Enter data about this relying party manually
Give it a friendly name
ADFS 2.0 profile
For now, skip the token encryption cert and click next
Enable support for the SAML 2.0 WebSSO profile and type in their token URL
Type in their identifier and click Add
Click Next, Next, Next, Close
Then add the Active Claims they will need although this can get tricky because many SAML providers are different in what they need.
When done, go to properties of your new relying party and go to the advanced tab and select SHA-1 for the secure hash algorithm.
This will get your most of the way. Let me know. Thanks, Dave
Thank you Dave you’re awesome. I’ll follow your advice and let you know if any qs.
I’m new to adfs staff so your site I a really helpful, practical starting from planning and design to implementation. All details that are missing on other sources.
Will explore your blog on other topics 🙂
Thank you again!!!
Quick note here. I thought I will ask them for metadata file URL and specify it at configuration step. Or it’s not an option in this scenario?
Definitely try to exchange metadata files with them, and hopefully they can use it. You may also be able to use their metadata to create the relying party application on your side. I didn’t suggest it because many SAML providers either don’t provide a
metadata nor can consume one. Hopefully, they do..
Dave, I preparing to submit SSL certificate request for ADFS/WAP servers at the moment, we using multiple UPN suffixes in our single domain environment, so users have emails or upns like: John.Doe@contoso.com or Jane.Doe@adatum.com or Tom.Eaton@treysearch.com
for example, so should I specify Subject alternative names in Cert request such as sts.contoso.com, sts.adatum.com, sts.treysearch.com, etc. Users will use email address to login to RP login screen. We are going to setup ADFS for Office365 Please advise. Thank
you
Carl,
What really drives this decision is device registration and when doing so, clients will try to resolve enterpriseregistration.. For example, if you have two UPN’s in the enterprise, you would want to ensure the SAN on the certificate was enterpriseregistration.contoso.com
and enterpriseregistration.fabrikam.com. You could still call your ADFS service name sts.contoso.com or adfs.contoso.com. The domain suffix is the part that has implications on device registration. Make sense. Let me know. Thanks Dave
Can we use one ADFS service configured in single domain environment with multiple UPN suffixes configured in AD
Thank you Dave!
Carl,
As long as the Subject Alternative Name (SAN) on the certificate contains the domain suffix for all UPN’s, like enterpriseregistration.contoso.com,enterpriseregistration.fabrikam.com, then yes.
Hi Dave, another question, from SP metadata file requirements for Claim type are as follows:
urn:oasis:names:tc:SAML:2.0:nameid-format:emailAddress
So I will create claim issuance Transform rule,
Mapping of LDAP attributes to outgoing claim types section, ->LDAP Attribute, -> E-Mail-Addresses.
Under Outgoing Claim Type, -> E-Mail Address.
Do I need to add another rule: Transform an Incoming Claim
Name: Email to Name ID.
Incoming claim type -> E-mail Address
The Outgoing claim type -> Name ID
Outgoing name ID format -> Email
Pass through all claim values
Please advise, thank you
Madina,
Go to the following link that talks about onboarding applications:
And search the page for "SAML: Claims, Claim Type & Format". In the second picture, I have a format of unspecified but from what you describe, you would need to pick email in the format dropdown. Some background on this – Yes, you will have ADFS issue the email
claim but then ADFS will then transform that email claim into NameID with a format type of email. You would typically configure this on the relying party configuration. Let me know. Thanks, Dave
Thank you Dave!!!
I have an interesting situation. We are using self-signed certs, and new certs were automatically generated and set as secondary. Before the new certs were automatically promoted to primary, we disabled autocertificaterollover and then manually promoted
them – and then re-promoted the original, soon-to-expire certs. This reverted the new certs back to secondary and allowed us a bit more time to organize with relying parties. Now we would like to set the certificateduration to 3 years and create new certs.
My question is, how should we do this? If we run Update-ADFSCertificate, will that create a third set of certs? Or will it overwrite what is now the secondary certs? Will I get an error? Also note I don’t want to use the -urgent switch, so the goal is to create
new 3yr certs and distribute to our RP’s and then schedule an ADFS outage on the weekend. Thanks for your help!
Paul,
First, run the following, which will enable you to delete the unwanted secondary certs:
Set-ADFSProperties -autocertificaterollover $false
Then manually delete the secondary certs you no longer want from the ADFS console. Then re-enable rollover:
Set-ADFSProperties -autocertificaterollover $true
Make sure your intervals are setup correctly:
CertificateRolloverDuration should be 1095
CertificatePromotionThreshold – This is how many days after generation should they be promoted to primary. This will be your threshold of how long you have to distribute to partners. Make sure this occurs before expiration.
Then regenerate another set of secondary certificates based on these internals:
Update-ADFSCertificate
Hope this helps. Let me know. Thanks,
Dave
Thanks Dave. Can we go through this process but skip the Set-ADFSProperties -autocertificaterollover $true step? We would then plan to promote the newly created certificates manually – and before the old certs expire.
Paul,
Yeah, that appears to work but you can’t generate a new certificate while autorollover is disabled so you’d have to:
Set-ADFSProperties -autocertificaterollover $false
Manually delete the secondary certs you no longer want
Set-ADFSProperties -autocertificaterollover $true, which will allow you to generate new secondary certs
Update-ADFSCertificate to generate new secondary certs
Set-ADFSProperties -autocertificaterollover $false
Manually promote the secondary cert to primary when you want.
It looks like new certs were created automatically after setting Set-ADFSProperties -autocertificaterollover $true. This is likely because we are within the auto threshold period. We will manually promote before the threshold period ends. This solution
allows us to better plan with our RP’s and minimize outages.
Thanks again!
Thanks so much Dave.
Just a quick question, from the above, you reckon that wildcard certificate is not recommended from your own point of view. Please could you highlight the disadvantages of using wildcard certificate for our ADFS/WAP servers? I need some information to present
to my manager on the need to go for separate SSL certificate instead of wildcard that we currently got. Thanks for your help as I look forward to hearing from you.
Olu,
The only place I don’t recommend the use of wildcard certificates is on the ADFS Proxy/WAP. These servers are supposed to be located in the DMZ, not domain joined, and provide a layer of separation between the internet and your ADFS servers. So as an additional
security measure, I don’t recommend the use of wildcard certificates on these servers. If any unauthorized user was able to logon to these servers and could export this wildcard certificate, you would have to revoke and replace this wildcard cert everywhere
it was installed, if you had all its locations documented. If you have no other choice but to use the wildcard certificate on the ADFS Proxy/WAP, I would recommend that when you import the certificate, you ensure that "Make Private Key Exportable" is disabled.
At the end of the day, there is nothing stopping you from using the wildcard certificate on these server so I see this decision as an additional security measure. Let me know if you have any questions.
Thanks so much for your help Dave. You are a star! Through your post I have been ale to convinced my manager and he has approved purchasing a public CA from Verisign. Thanks once again
Hi, our FS name is ds.public_company.com where public_company.com is a registered external domain name. Internally, our domain is company.phco. So for the SSL cert for DRS and WAP, it needs to have both "ds.public_company.com" and "enterpriseregistration.company.phco".
However, no public CA will issue a SAN cert that includes an unpublished internal domain and I cannot register a ".phco" domain. Does this mean I have to use an internal SSL cert? What are my options? Thank you.
lwong,
In regards to mobile device registration, to make the end-user experience as easy as possible, the CN or SAN on the SSL certificate has to match the UPN of your users. What is your users’ UPN and their email address suffix?
Hi dgreg,
The service name is actually ds.petersoncat.com and petersoncat.com is a registered domain. The user UPN is @ptsn.phco, but their email addresses are @petersoncat.com. Thank you.
lwong,
Sorry for the delay here. If you absolutely cannot change your UPN, then the only options you have is the following:
1.) Install and configure alternate ID so ADFS can log them in with another attribute (email).
2.) The other option is to train your users to type in their email address during DRS discovery but then have them type win their UPN during login, which doesn’t sound like a good nor successful experience so I would go with #1.
If you go with #1, then you would add their email suffix to the SSL certificate in the SAN or just get a wildcard.
Hope this makes sense. Let me know. Thanks, Dave
what certificate is exchanged between the ADFS (3.0) and the WAP every couple of weeks? Also if this is being load balanced what SSL service type is required to allow the certificate exchange to happen. I currently have Netscaler set to use SSL_Bridge
(which hands back the traffic fully encrypted) but the certificate exchange between ADFS/WAP breaks every couple of weeks. the only way to fix is to change host file to one of the ADFS servers and then re-run the WAP wizard.
I believe your middle name is either hidden character or ?
There is one thing that is not mentioned here. However little it is causes a headache. What configuration is needed for Certificate Based Authentication whether it be the Primary Method or MFA Method of Authentication?
Typically any document I have come across is make sure you have your server certificate loaded in the Trusted Root Store if you are using an Internal CA such ADCS the Web Server Template is just fine (it has server authentication as an EKU). The User template
is just fine also for the user certificate. You then Enabled Certificate Based Authentication and when you attempt to log on you are presented with a pop up box to select your user certificate.
Now lets say you want to use a public certificate for your ADFS server. Yes you should make sure that Server Authentication is part of the EKU, in most cases you have to add that to your CSR. When you then have your Public Certificate you will most likely have
2 EKus listed. Client Authentication and Server Authentication. You then add teh certificate to your ADFS server. Typically thats all you need, but the moment you enabled Client Based Authentication and try to authenticate with a user cert for some reason
the Certificate Popup no longer comes up. You’ve verified the Public Certificate is in the correct store, Port 49443 is enabled inbound and that the Public Cert has the correct settings in terms of the Subject, SAN, EKU and KU but still no pop up.
Well its true you do need Server Certificate listed as an EKU, However for Certificate Based Authentication to work you need to Disable the Client Authentication EKU. Once you do that the Certificate Prompt returns.
Hi,
Could you explain why you do not recommand to use the SSL certificate for signing and decrypting ?
Thanks
Hi, I would like to encrypt the token when it is sent to the Office 365 relying party, but from reading your article it looks like I’ll need the public key from Office 365 to be able to do this.
1. Where do I get the public key from?
2. How would I get notified that the Office 365 relying party certificate has been replaced as it has come to the end of its valid period?
I’ve searched for ages but the information seems to be lacking.
Thanks,
Stuart
StuartT,
I talked to our product group about the encryption certificate you’re looking for and they told me what I suspected – Azure AD/O365 doesn’t support nor publish a token encryption certificate. Do know that that token will still be digitally signed, which ensures it can’t be modified and is also protected within SSL encryption, which ensures privacy.
Hi Dgreg,
our ADFS server will be running in our private domain, mydomain.local. We would like to use a public SSL certificate, say sts.mycompany.com, which will be registered public. You tell that “Your ADFS SSL certificate doesn’t have to match your Active Directory forest or domain name.” Our ADFS name will then be called sts.mycompany.com and not sts.mydomain.local, right?
Thank you for your feedback.
twinsco,
Yep, your ADFS SSL certificate doesn’t have to match your domain/forest name, so if you forest name is domain.local, you absolutely can get an SSL certificate of sts.domain.com. There are really only two requirements for this:
You actually own the domain name that you’re getting the SSL certificate for.
This one isn’t required but if you plan to have external access, make sure that the DNS domain name that you pick for the SSL certificate is resolvable from inside and outside your corporate network.
With saying that, there may be times where you want the SSL certificate domain name to match your user’s UPN’s – if you plan to do workplace join on Windows 8/8.1 or Windows 10 devices but if you plan to use O365 or Azure, I’d just recommend you actually workplace join these devices in Azure rather than ADFS since it can provide all the same benefits without having to worry about having SSL certificates that match your UPN. If you domain is domain.local, what is your user’s UPN’s?
Thank you for your prompt respond dgreg. UserPrincipleName of the users is by default @mydomain.local. Is it necessary to add an additional upn to the domain such as @mycompany.com which is the email address of the user at the same time?
twinsco,
Having a “non-routable” UPN like @mydomain.local won’t work when integrating with Azure AD/O365. Consequently, you have a few options that will still enable you to move forward and consume these services:
Update everyone’s UPN to match their email address. This should ensure their UPN is then publically routable, plus SSO will be easy for them because they’ll be able to login with their email address, because it matches their UPN. This is the ideal outcome.
The other option that is less than ideal and if you can’t do the above recommend for some reason – If you are planning to use Azure/O365, you can configure the Azure AD Connect server to synchronize their email address value to Azure AD as their “UPN”. Then on ADFS, you would need to change the ADFS claims rules to send their email value as their “UPN” and then install the AlternateID hotfix on your ADFS servers to ensure they can login with their email address. Some caveats of this approach are that certain mobile applications may not work and/or become really confusing for the users to login with.
Here is a non-Microsoft article that appears to cover the second option really well:
Hi Dave,
There’s a requirement wherein i have two web apps (both will be authenticated by Azure AD and both are SAML supported). I have to enable SSO.
Question is :
1) Do i need ADFS? or can Azure AD directly communicate with local AD?
2) Is there any specific requirement on Azure for Java based applications?
P.S. : I am very new to Azure.
Thanks in advance !
Lipsy,
I answered most of this in the comment below this but here’s more information. Azure AD supports SAML as does ADFS. Many customers over the years stood up ADFS to provide their employees with SSO to many SAML applications but over the years as they accumulated many SaaS applications, they eventually got tired of having to manage all that ADFS infrastructure, updating certificates, etc. Consequently, many of my customers are now looking to get out of the business of hosting ADFS and are looking to Azure AD to provide this SSO integration for them. With that being said, here are two approaches my customers are taking:
They use Azure AD Connect with password hash sync and have no ADFS. Then use AAD as their SSO infrastructure to SaaS apps including SAML-based applications.
Or they do stand-up ADFS and only federate with Azure AD and still use Azure AD as their jump-off spot for SSO integration with SaaS apps including SAML-based applications. This way, their ADFS only has one federated application – Azure AD. This is a heck of a lot easier to manage than having to federate with your ADFS with all those SaaS applications and the management that goes along with it.
Or lastly, you can stand-up ADFS and do all the federation integration with all the SaaS and SAML applications directly to ADFS. But like I said, many customers are getting tired of this approach. They’re willing to pay for SSO and Identity as a Service via Azure AD.
Dgreg,
Thank you for providing such a useful information. I will be using Azure AD connect with password hash sync with no ADFS.
Can you please help me in understanding how Azure AD will be issuing SAML tokens to SaaS application (SAML 2.0 supported)? If possible could you share some links from where i can get idea about the same.
Lipsy,
Azure AD can definitely provide SSO capabilities but your users will need accounts in Azure AD one way or another to have access to Azure AD so they have access to these SSO capabilities. Here are the ways you can have do that:
Install Azure AD Connect with password hash sync which will push your on-premises Active Directory accounts to Azure AD. With this approach, you won’t need ADFS.
Install Azure AD Connect WITHOUT password has sync which will push your on-premises Active Directory accounts to Azure AD. With this approach, you WILL need ADFS.
Don’t install Azure AD Connect nor ADFS and manually or via script, create cloud accounts directly in your Azure AD tenant. With this approach, these users will have a separate password from their on-premises Active Directory password.
Here is an article that covers these options well:
Thank you for your prompt response dgreg.
I would like to know is there any harm in installing Azure AD manually if i don’t have any need of keeping different passwords for on-premises AD and Azure AD. Also if i created users manually at Azure AD tenant, then how will local AD and Azure AD sync with each other?
Secondly i would like to know about any specific libraries/jars which might be needed for enabling SSO in java based applications or there is as such no requirement for specific libraries?
Your response are the trade-offs between creating cloud accounts with separate attributes and password versus using Azure AD Connect, which can keep those attributes and passwords in sync. If you want everything to remain in sync between Azure AD and on-premises AD including the password and don’t want to have to build out ADFS, then Azure AD Connect with password hash sync is the way forward. Once configured, your users can then log into Azure AD with their domain credentials and Azure AD can then provide SSO capabilities to other SaaS, mobile applications, etc.
Concerning your second question, it really depends on what sign-on protocols this Java application supports. If it’s a web-based application and supports SAML then it wouldn’t need any additional libraries to integrate with Azure AD. If it’s a thick client application and supports OAuth or OpenIDConnect, then it could also integrate with Azure AD for SSO. Another option is to include the Active Directory Authentication Library (ADAL) in your application, which can perform all this SSO heavy lifting for you.
I have a requirement to federate with a SP that supports only AES128 encryption algorithm & RSA-OAEP transport, we are running ADFS 3.0 on Server 2012 R2, can ADFS be configured to use AES128 on a per Relying Trust basis. Does selecting RSA1 on the Advanced Tab of the Trust accomplish this? We are using the self signed Token Certificates and our communications certificate details are:
Signiture algorithm: sha256RSA
Signiture hash algorithm: sha256
Issuer: DigiCert SHA2 Secure Server CA
Public Key: RSA (2048 Bits)
Thumbprint Algorithm: sha1
You mentioned above the following:.
But why is it okay NOT to use an encryption certificate?
Hi Dave, I figure your middle name is “DFS” 😀 as it is very challenging technology and you seem to master it. I wonder from a security perspective, if you can refer to a MS article on implication of not using token signing certificate at all, or using sha1 as advised by the partner. Thanks a lot
With ADFS, token encryption is optional but token signing is required. Consequently, there is no way around not using a token signing certificate. You can of course get a certificate from a public CA or from your internal PKI CA so the option is yours. Token signing ensures that if someone were to intercept the token and try to modify it, it would be rendered invalid. Plus being signed with the private key of ADFS ensures it came from the known identity authority. Encryption just ensures data privacy but most times, SAML tokens don’t have much sensitive data within them. SSL is always required which provides some level of data privacy just in case. When you speak of SHA-1, are you talking about the secure hash algorithm configuration on the individual relying party applications or on the actual certificate?
Hi Dave,
I’m still a bit, or maybe alot, confused on the purpose of the service communications certificate and its use
In our environment (proxies in DMZ and servers internal), our SSL cert and service communications cert are different
I understand the purpose and use of the SSL cert within ADFS, but I can’t wrap my arms around the use of the service communications cert
The only thing I can find is ” This certificate enables WCF message security for securing communications between federation servers.”
So is it for ADFS service to service communiction, and is this only valid for WID deployments?
Any help or direction appreciated
Thanks,
hi greg.
I am facing this problem while configuring adfs on different box.
I have one machine for AD DS and ADCS
one machine for adfs.
I am unable to do Initialize-ADDeviceRegistration I get the following error on the adfs machine.
—————————————————————————————————————————————-
Initialize-ADDeviceRegistration : The current user is not a member of the Enterprise Admins group of the target
machine’s domain.
At line:1 char:1
+ Initialize-ADDeviceRegistration
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Initialize-ADDeviceRegistration], PrerequsiteFailedException
+ FullyQualifiedErrorId : PrerequisiteTest,Microsoft.IdentityServer.Deployment.Commands.InitializeDeviceRegistrati
onCommand
——————————————————————————————————————————————————–
I have added the service account in DC using the following commandsAdd-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)
New-ADServiceAccount FsGmsa -DNSHostName adfs. -ServicePrincipalNames http/adfs.
Any help is greatly appreciated
For workplace join (described in #7 above): the correct spelling for the SAN on the SSL cert: EnterpriseRegistration.YourDomain.Com
Great series BTW !
Very helpful.
I have an ASP.NET web application which is accessible through, and. I have one SSL with CN = ‘abcd.ppp.com’ and SAN = ‘pqrs.ppp.com’, ‘wxyz.ppp.com’ ,’abcd.ppp.com’. I want to integrate this site with ADFS. For that, I am generating application metadata using Windows Identity Foundation. I am using the above said SSL as token signing certificate and linked with my application in IIS too. I have provided in the application URL field in the Windows Identity Foundation wizard. I have read in a blog that the value of this URI field in WIF wizard should be exactly same as CN of the certificate installed in IIS used with this web application. So should I be able to access my application with https:// abcd.ppp.com/product and with correct ADFS redirection after ADFS integration? or I will be able for only? If it should work, then fine, else how can I configure this when I have multiple SAN. Also if I want to host my site behind FortiWeb server. My website in my app server is using port 4443 and on fortiweb firewall is translating port from 4443 to 443 on the fly. So what URL now should I provide while generating application metadata? Should it remain or I have to eliminate the port no 4443 now? The external DNS entry is pqrs.ppp.com with an IP that corresponds to a fortiweb server and the internal mapping is an IP which resolves to my real server itself. Please answer my question ASAP, I have a production deployment this weekend once these things are fine in QA.
thanks…
Sorry, one correction-
I have read in a blog that the value of this URI field in WIF wizard should be exactly same as Subject of the certificate installed in IIS used with this web application.
Should it remain or I have to eliminate the port no 4443 now?
While generating CSR, I see Subject has CN and I have option to specify Alternate Name where we provide a few more DNS name.
Now after getting the certificate, there are 2 fields, one is Subject, the other is Subject Alternate Name having those other DNS name.
So is it possible to provide any value which is present in either SAN or CN of the SSL used in IIS, in application URI field of the WIF wizard?
Mine is NOT a wildcard SSL. Can I provide multiple URIs being comma separated or can I edit the application metadata file to add more audience URIs?
Hello dave, can the public certificate contain these values :
adfs.name3.net
certauth.adfs.name3.net
enterpriseregistration.name3.net
The server configuration is internally two ADFS servers behind load balancer and in dmz two WAP servers again behind load balancer.