SAML SSO: Is AD Connect one-way connection enough?

Radiolontra 136 Reputation points

my local AD is connected to Azure directory using ADConnect, in a one-way connection.
Users are autenticating to 365 services using domain credentials.
No password writeback is available, and we're happy like this, at the moment.
From networking point of view, everything is very simple, and i dont have any exposed services required for the connection

Now, for a small subset of these users, i might want to buy Azure P1 licenses, and enable SAML authentication on a cloud service we use.

What i dont understand, from Microsoft architecture documentation, is if i can do it with my existing infrastructure o if i need to deploy more internet facing servers in order to setup a full federation, with bi-directional sync

Any advice will be appreciated!

Microsoft Entra ID
Microsoft Entra ID
A Microsoft Entra identity service that provides identity management and access control capabilities. Replaces Azure Active Directory.
20,476 questions
0 comments No comments
{count} votes

Accepted answer
  1. amon 121 Reputation points Microsoft Employee

    Hi @Radiolontra

    I'll divide the answer in to 3:

    1. Enabling SAML authentication for an app
    2. AD Federation
    3. Bi-directional sync
    4. SAML authentication using an identity in Azure Active Directory -
      When using SAML, you delegate the authentication and authorization to your app to an external identity which you trust, in this case Azure AD.
      Since your users are synced to Azure using ADConnect, you can use your AD identity to authenticate.
      Note: * this will not require any additional licensing and is available in the free Azure AD subscription *
      To authenticate an app, you need to create an application in you AD, enable SAML authentication and configure your app. It's actually pretty straight forward (unless you require special configuration) and here is a great explanation on how to set it up.
    5. Active Directory federation is an extension to your local environment, to enable federation for internet facing application. This document explains it better than I could. If you sent up ADFS, you will be able to federate you applications authentication (and authorization) to your local AD, but this will require you to set up ADFS and expose it to the internet.
    6. From how I read your question, bi-directional sync can mean either of two things :
      a. Password hash sync
      b. Seamless Single Sign-On

    Bottom line (if understood your question correctly) you can set up SAML authentication for your app in your current configuration.

    1 person found this answer helpful.
    0 comments No comments

5 additional answers

Sort by: Most helpful
  1. amon 121 Reputation points Microsoft Employee

    Hi @Radiolontra

    Regarding the pricing, check out the pricing here in the row "Single Sign-On (SSO) (unlimited)". You can have unlimited applications as long as they are cloud applications. As soon as you start integrating on premises apps you will require a license (take a look at footnote 2)

    Regarding password write back, that is the password hash synchronization - it's a two way sync (if I understood your setup correctly currently you have only 1 way from your on-prem to the cloud).

    1 person found this answer helpful.
    0 comments No comments

  2. VipulSparsh-MSFT 16,251 Reputation points Microsoft Employee

    @Radiolontra Single Sign on with a SAML app in Azure AD is free from Azure AD side but can be a premium service from the App side. So check which service plan from the application side you need to implement.

    You do not need ADFS for federation, (You will be able to do this with your existing infra) as in your scenario Azure AD would be your federation entity to the SAML App.
    You will need Atleast Azure AD premium license (P1) to be able to enable password writeback, where the password reset on cloud is synced back to on-prem (You need to run the Azure AD connect wizard for this and check the password writeback option)


    If the suggested response helped you resolve your issue, please do not forget to accept the response as Answer and "Up-Vote" for the answer that helped you for benefit of the community.

    1 person found this answer helpful.
    0 comments No comments

  3. Radiolontra 136 Reputation points

    Thank you very much for the detailed answer.

    Most important for my main concern is i can enable sso for my cloud application without changing my infrastructure, and this seems out of doubt.
    I'm still dubious about licensing, tough. In my Azure portal i can add the app i need from Microsoft gallery, and everything looks like it will permit me to go on and enable access for my app.
    But in many places on the internet, and on my licensing portal itself, it looks like all the "Account and Security" features are NOT included in Standard subscription, and they are available in Microsoft 365 Business Premium. Unfortunately most of Microsoft online comparisons between licensing plans dont specifically show the Azure and sso details

    As per point 3

    • Password hash sync is what i'm using now, with local AD sending password hash to Azure via AD Connect server
    • Seamless SSO , i'll take some time to read that page but i think it's something i dont need now

    What i might want to enable in the future is password writeback. I mean a user can update the password from any office 365 web page, and that password will be pushed to my local DCs . It is included in Premium license, so if i have to upgrade licenses, it might be worth enabling writeback too.
    Hence my last question is: Pwd writeback will work with my current AD Connect Server or it requires some frontend listening for Azure sync push ?

    thank you again

    0 comments No comments

  4. Radiolontra 136 Reputation points

    @VipulSparsh-MSFT you mean check licensing of the Non-Microsoft application i need to authenticate to Azure, right?

    Regarding password writeback, enabling it in AD Connect setup, means it is enabled for all users, and all of them require P1 licenses? Or i can also distinguish between who i want to be able to writeback and who dont?