Suppression of SSO from the architecture

[gwendal55]

My client wants to remove SSO from its architecture, as well as ADFS. Without subscribing to the Azure AD Connect solution. If possible, he would like the maximum configuration to be possible from the Office 365 administration center. To do this, he would first like to make an impact study of the removal of SSO and ADFS. Can you assess the impact on current operations? What would be the risks of incidents? Alternatives in Office 365 configurations? What details of information should we collect and check before any change ?

[#2]

@gwendal55You can use Azure AD only, without using AD. It's entirely possible. But without AAD Connect (or AAD Cloud Provisioning), you would have to manually manage users in two separate directories. Users would potentially end up with two passwords to use.

Is the goal to go cloud only for authentication or will you still required Active Directory?

[#3]

@Mark Lewis 

The architecture is with one-way synchronization. Any creation or modification must be done in the AD and it is synchronized afterwards in Office 365. Management is done from the AD. The customer wants to install a secure gateway to authenticate users with an HR number before they access Office 365. Suddenly all other solutions are excluded (Azure AD Connect, SSO, ADFS). Users will not have two passwords, but authentication with a password and an HR number. Regards, Gwendal IDOT.

[#4]

@gwendal55AAD Connect doesn't authenticate users. It is provisioning/updating users, syncing passwords and where enabled doing password write-back.

I don't know enough about the Secure Gateway (I have seen your other post on this) to advise on this.

[#5]

@gwendal55 

Do you have a current IDP solution for the HR users?

You could look into products by Okta.

[#6]

@gwendal55 why would they want to make the user experience worse? Not a single user will like this change.

[#7]

@gwendal55 Just to make this clear. Azure AD stays in all cases the trusted IDP for M365/O365 services (or better saying so called 1st party services developed by Microsoft including Azure Services) and depending on the service being accessed and client application it uses WS-TRUST, OAuth/OIDC or in some cases SAML protocols.. so even if a user identity is confirmed/authenticated by the "customers" IDP (ADFS/Secure Gateway/PingFed, Okta, whatever solution, etc).. the refresh and access tokens for O365/Azure services always come from AAD. In fact you can not replace AAD with your own IDP/solution. You can tell AAD to redirect the user to your own IDP for authentication (using federation/or Conditonal Access custom controls), but it has to return the user to AAD to finally get the refresh/access tokens.

How you control authentication on customers IDP to confirm the user identity is up to you and capabilities of the solution..this can be forms-based, SSO with kerberos, FIDO, with and without MFA etc... not to say that you can do all this with AAD natively.... and do not forget device identity / compliance.. 

Furthermore if not using MS IDP (AAD and/or AFDS) you loose certain functionalities, like Cert Trust Keys for Windows Hello for Business... 

You might want to read a bit here https://docs.microsoft.com/en-us/azure/active-directory/develop/v2-overview

... to get a better understanding https://docs.microsoft.com/en-us/azure/active-directory/develop/authentication-scenarios might be a start.

Quote:

"Any creation or modification must be done in the AD and it is synchronized afterwards in Office 365. "

If you do not use Azure AD Connect.. you will need to implement your own IAM user provisioning system.. and you can not configure everything on-prem... you will need and MS Graph Interface from the IAM system.. 

and more.... I would recommend at least to build you own test environment to get more experience and either consult Microsoft Services directly or an experienced system implementer, before you continue... 

[#8]

@gwendal55 - you can get rid of ADFS and still keep SSO and authenticate on premise with Azure AD Connect. Search for Passthru Authentication.
I am not clear on your point about Secure Gateway and authenticate via HR system. HR system can act as identity source, but you don't have to rip apart your whole Azure AD Connect infra for it. Depending on which HR system, you might be able to fit it right in. (Look for Azure AD identity inbound provisioning).

Hope this helps.

Vik