This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Sophos Central and Azure AD federation setup and behaviour

I've setup the Sophos Central Azure AD federation and am slightly puzzled by the process and behaviour.

It seems like an Admin or Standard user still has to create a password in Sophos Central before the Microsoft integration will work.

So, I’m not understanding the purpose of this integration if a user needs to create a password for Sophos Central anyway. It does defeat the purpose of a user using existing credentials. The user object already existed in the Sophos Central console so why did we need to create a password?

Other products that use Azure AD integration are happy to match against account ID without having to have the user create a password that is not used.



This thread was automatically locked due to age.
Parents
  • Just to be sure. The Point currently of federated sign is to relay on Microsofts "Yes / no" Authentication.

    We are not Syncing any passwords with Microsoft. 

    The Feature request would be "please generate predefined passwords in Central to enable the user". 

    Most likely other products uses this approach (even Azure does the same. It generates a password for you and you can change it or leave it and sign in with your federated sign in). 

     

    __________________________________________________________________________________________________________________

  • Most other product that I use that do a federated login don't also have a local password component. Login is allowed so long as they are a member of a group or there is a user object (with permissions) with a matching ID (email address). There is no password sync.

     

    It sounds like you still create a local password which would in theory allow a user to login either with Microsoft account OR the local password.

     

    From the end use perspective, they don't care about a Sophos ID and most like it means little to them. They want to login with an existing authentication method they know and trust.

    If Sophos needs to create a local password for this to work then do it in the background as a long random password and don't bother the user.

    The barrier to entry is high if we have to ask a user to create Sophos ID in order to be able to use the login with Microsoft function, in order to be able to use the self service features.
    It doesn't happen.

     

    So yes, if my request needs to be "please generate predefined passwords in Central to enable the user", sure, consider that the request. 

    It's something the user shouldn't see or be bothered with.

Reply
  • Most other product that I use that do a federated login don't also have a local password component. Login is allowed so long as they are a member of a group or there is a user object (with permissions) with a matching ID (email address). There is no password sync.

     

    It sounds like you still create a local password which would in theory allow a user to login either with Microsoft account OR the local password.

     

    From the end use perspective, they don't care about a Sophos ID and most like it means little to them. They want to login with an existing authentication method they know and trust.

    If Sophos needs to create a local password for this to work then do it in the background as a long random password and don't bother the user.

    The barrier to entry is high if we have to ask a user to create Sophos ID in order to be able to use the login with Microsoft function, in order to be able to use the self service features.
    It doesn't happen.

     

    So yes, if my request needs to be "please generate predefined passwords in Central to enable the user", sure, consider that the request. 

    It's something the user shouldn't see or be bothered with.

Children