This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(44.800000000000004, 23%, 14%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EI%3C/text%3E%3C/svg%3E)
Hi
Thanks
I'm not sure you will get a lot of answers to your original post because it's quite un-precise.
Maybe you can add more information in order to understand what you're trying to do and what is your context deployment (in short).
Thanks for your comment.
We configured ADFS for O365. On properties of relaying trust party on Encryption Tab no certification is defined. So, my question can we setup encryption certificate in this case?
My second question is regarding the Token encryption and Token signing certficates. Both are selfsigned not issued by certificate authority. So is it recommended to change those certificates from selfsigned to signed by CA? Because I heard that's it's recommended to let's them selfsigned and I want to have a confirmation.
Hope it's more clear
First of all, you do not need ADFS to have Single Sign On between your on-premises clients, you can use Azure AD Connect Seamless SSO. Have a look if you are interested: https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso.
Then, the token issued by ADFS is not encrypted. So there is no encryption certificate to use on the trust. That's expected. Note that the token is signed and it is transported over TLS.
By default, token signing and token decrypting certificates are self-signed. Those certificates automatically roll-over and unless you have a interal policy that prevents you from using self-signed certificates, you can just keep those as-is. Certification revocation is not performed on those certificates.
Thanks Piaudonn for you answer.
Sorry for the 1st question I forgot to precise we have hybrid architecture that's why we use ADFS (internal policy) and to configure the alternate login ID
If you have better suggestion, it's more than welcome :)
It's more clear by your answer
Thanks
Glad it helped!
I am not sure what you call hybrid architecture. If it is about the fact you have hybrid identity (the users and devices exist both on-premises and in the cloud) you can still use the authentication mode I mentionned above. If you want the authentication to always stay on-premises, you can also achieve SSO for on-premises users with the Pass-Through Authentication with the SSO option. It supports alternate ID too.
you're right, I mean hybrid Identity. actually the ADFS is implemented but after reviewing the Pass-Through Authentication with the SSO option, I think will migrate shortly to this mode. it's better.
juste one detail, for encryptions certificate to use on the trust, I refered to the article https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/design/best-practices-for-secure-planning-and-deployment-of-ad-fs/
where they mention
Use token encryption, especially if you are using supporting SAML artifact resolution.
Encryption of tokens is strongly advised to increase security and protection against potential man-in-the-middle (MITM) attacks that might be tried against your AD FS deployment. Using use encryption might have a slight impact on throughout but in general, it should not be usually noticed and in many deployments the benefits for greater security exceed any cost in terms of server performance.
can we Apply this in case of O365 ADFS authentication?