Windows 10 sign in with azure AD not working

Showing results for 
Search instead for 
Do you mean 
Reply
Contributor I
Posts: 16
Registered: ‎03-26-2017
#1 of 6 2,837
Accepted Solution

Windows 10 sign in with azure AD not working

For my next seemingly insurmountable challenge, I am now trying to log into a Windows 10 PC that is joined to my Azure AD, which is federated with Centrify cloud identity. I followed the steps in this video: https://www.youtube.com/watch?v=GROy6pIpYRQ

 

I get as far as adding the machine the Azure AD - this part works fine, I type in my email address and get redirected to the centrify when adding the machine to the Azure AD domain. The join appears to work, and I can see it listed under Settings->Access school or work.

 

In the video, once the PC is joined to the domain, the presenter simply logs out and then logs in with a username and password, but it's not clear what this password is! He acknowledges that the user is not an Azure AD user, so it cannot e an Azure AD password. I assume this would be his centrify password, however when I try to log in this way myself, I get denied saying that a my password is incorrect - I assumed it was because Centrify usually requires MFA to log in. However, In the video the user requires an MFA token to sign in when joining the domain, same as my setup, but they are not prompted to enter one when logging into windows. Why is this? What password is he typing in? Is it the Centrify one, if so, why does he not get an MFA prompt?

 

 

This demo shows Centrify Identity Service's support for the Azure AD join feature for Windows 10. This was the first time I was actually testing it so it worked like a charm.
Centrify Guru I
Posts: 2,295
Registered: ‎07-26-2012
#2 of 6 2,824

Re: Windows 10 sign in with azure AD not working

[ Edited ]

@Cory,

 

Hello and welcome back to the Centrify community. Our apologies for the delay.

I am the author of that video.  2015 feels like ages ago.  To give you some context, I have a personal blog that I use to share ideas and practice demos (hence the low production quality!) Smiley Very Happy 

 

Let's see if I can help.

 

"I get as far as adding the machine the Azure AD - this part works fine, I type in my email address and get redirected to the centrify when adding the machine to the Azure AD domain. The join appears to work, and I can see it listed under Settings->Access school or work."

 

Please note that this video is very old and we are talking Windows 10.  I'm not sure if you're aware but Win10 is not just one operating system but several.  As a matter of fact, the version of Windows 10 I used in that video (1507) is already EOL!!!!!  Note that even the terminology has changed "Access school or work"  is now  "Connect to school or work"  and as of Windows 10 Spring Creators Update 2018 (v 1803, released  30th) the capabilities have changed.

 

Our own capabilities have changed too since that video!!

 

The most important thing for me to understand is the underlying requirements (a.k.a what you need to accomplish).  Getting over the hump of "registration" is one thing, but the underlying requirement dictates what method to be used.   This is because just like Microsoft we support the "clientless"  and client-based approach and the target user populations and capabilities are different for each method to be used.

 

In the video, once the PC is joined to the domain, the presenter simply logs out and then logs in with a username and password, but it's not clear what this password is!

 

The password was my centrify domain password.  The reason why I used this at the time was to illustrate device registration with O365 via Centrify; the system is still joined to AD.  The goal was to illustrate that you did not have to worry about ADFS and DirSync and that you could leverage Centrify as the IDP in this context (at the time, Microsoft had not released the improvements to their O365 enterprise integration).

 

He acknowledges that the user is not an Azure AD user, so it cannot e an Azure AD password.

 

Yes I did, however, we have to understand Microsoft's terminology here.  "Azure AD"  means different things in different times.  At the time, Microsoft was trying to make a distinction between using "Azure AD" as a directory vs. Domain-integrated Office365.  This does not make sense today given that was almost 3 years ago, but that's not important.

 

I assume this would be his centrify password, however when I try to log in this way myself, I get denied saying that a my password is incorrect - I assumed it was because Centrify usually requires MFA to log in.

 

Now things are getting interesting.  The reason why I got prompted for MFA is because the administrator of the Centrify tenant configured the authentiation profile for systems without a cookie to require Identity assurance by MFA or Step-up challenge.  Note that this is configurable.  However, an additional challenge in this context is the right thing to do.

 

Also, the way this works is that Windows 10 will look at the user's domain suffix and it will interrogate DNS for a set of  AutoDiscovery records (enterpriseregistration and enterpriseenrollment), this in turn tells Windows 10 which services to use for the purposes of MDM Management.  If you are able to locate the service, but your credentials don't match, then you can't register the device with the service.

 

However, In the video the user requires an MFA token to sign in when joining the domain, same as my setup, but they are not prompted to enter one when logging into windows. Why is this? What password is he typing in? Is it the Centrify one, if so, why does he not get an MFA prompt?

 

I think we finally got to the root of what you want to accomplish.  It seems that your requirement is to provide MFA at login.

 

I was not prompted for MFA because this won't give you MFA, this is what Microsoft calls "Device Registration" that's typically reserved for limited capabilities like EMM (MDM) just like I stated above.  This table from Microsoft explains the differences of what they provided at the time:

chart.PNG

Source: https://blogs.technet.microsoft.com/trejo/2016/04/09/azure-ad-join-vs-azure-ad-device-registration/

 

Your requirement

Now, let's satisfy your requirement.  To be able to provide MFA to your systems you need to use the Centrify Agent for Windows. 
agent.PNG

This is part of Endpoint Services or Privilege Access Service.  It accomplishes everything on the right side of the chart and the following:

 

With Apps/Endpoint Service

  • MFA at login (console, remote, screen unlock)
  • Self Service (Password Reset)
  • Basic MDM (location, remote wipe)

With Infrastruture Service

  • Centrify Zone-based Access Control
  • Privilege Elevation (with or Without MFA)
  • Session Capture and Replay (with a DirectAudit infrastructure).

 

The requirement is for the system to be domain-joined.  This requirement will go away soon.

 

The way you deploy resembles more enterprise software.  You can use any tool like (GP, SCCM, Altiris, LANDesk, etc).  Centrify provides an MSI package and a transform file (MST).

@StevenF has done a great job at documenting some of these.

 

To support one of Steven's blogs, I even created a video series to go over the GPO-based deployment.

Note that since version 2018, the end user does not have to be over VPN or on premises to perform this setup.

Other resources:  https://community.centrify.com/t5/TechBlog/Labs-Securing-Windows-Cloud-Instances-with-Centrify-Auto-...

 

R.P

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify:
Contributor I
Posts: 16
Registered: ‎03-26-2017
#3 of 6 2,783

Re: Windows 10 sign in with azure AD not working

Thanks for the very detailed reply, I really appreciate you taking the time to help with my issue. Your guess about my requirements are not quite correct however.

 

To provide some background context, I am running a 100% cloud business, we have no on-prem infrastructure (or even any fixed premises really), so the business has so far run on a combination of Zoho apps, freshdesk, and a few other cloud services. I initially ran with Centrify cloud identity because it was the best solution I could find that would give me cloud SSO with MFA for all the other web services we use. I tried a bunch of other options like OneLogin, Jumpcloud, Auth0, they all had shortcomings, and I have been pretty happy with my choice to run with Centrify so far.

 

What has changed recently is that I have decided to move all our business apps (email, calendar, files, etc) to Office 365. I ran into one too many limitations with Zoho, and since I was paying for O365 licenses anyway to use the desktop apps, I figured if I was going to move out of Zoho, O365 was the logical place. It has causes me a world of pain so far, but mostly because I am not using it in a "pure microsoft" way.

 

You've probably seen a few other posts I've put up recently about other issues I've had integrating with o365. Office 365 does not play nicely with users external users that are not coming from a real on-prem AD via ADFS - that's my experience so far. With help from the community here, I've managed to get O365 sign-ins working with my Centrify users, via the SAML redirect sign in page, which is what I wanted. Except for skype for business, but from what I can tell that is not going to be worth the hassle.

 

Now, as far as Windows goes, my requirements are a little bit different. I don't specifically want users to sign in with Centrify, nor do I need MFA at the login screen. The only reason I'm trying to get Win10 sign-in with Centrify working is because my Office 365 users are provisioned by Centrify, and what I really want is for users to be able to sign into Windows with their office 365 accounts to get SSO for all the integrated services like Office apps, onedrive for business, sharepoint, etc. As a secondary requirement, I want to use Azure AD to manage policy on my domain joined devices, essentially replacing a real on-prem AD with Azure AD (and maybe Intune if I need it). If it's also possible to somehow get SSO for my other web apps that use Centrify, using the windows login credentials, that would be a huge bonus, but it's not a show stopper if not.

 

So my "problem" at the moment is that I have joined my laptop to Azure AD, I can see it under devices in the Azure AD console, but I cannot log into Windows with my Office 365 (centrify) credentials. When I try to log into Windows using my office 365 user (i.e. cory@myo365comain.com) and I enter my Centrify password, it seems like it does make a remote call of some kind because it thinks about it for a few seconds, but then I get a "incorrect username of password" error.

 

My assumption as to why this was failing was because my "default other login" policy for Centrify is to require 2 factors, and the windows 10 sign in experience does not have any mechanism to support this. I tried creating a new login profile in Centrify that only has password set for first factor, and nothing for 2nd factor, then I attatched it to a sign in rule for "device os = windows"  in the Office 365 Centrify app - still no luck.

 

I spent the better part of 2 days combing through Microsoft and Centrify doco looking for tips on how I could get this to work, but none of it seems to apply to my use case - the assumption is always that there is an On-Prem AD somewhere, which both Centrify and/or Office 365 are linked to. I don't have that, my office 365 users don't have a domain password, or any password that is not their Centrify password. I cannot even set a password for them in Azure AD because Azure AD correctly identifies them as foreign users, and tells me to manage them at the source.

 

I take your point about different versions of Windows 10 and the functionality has probably changed under the hood - for the record I am using Win10 Enterprise 1709, build 16299.431.

 

That is basically where I'm at. Right now, if I can at least get windows 10 sign in using an office 365 account that is provisioned via Centrify, I will be happy. Based on my experience so far, I have started to doubt that it's even possible, it seems like what I'm trying to achieve is an unsupported edge case, though I find it hard to believe that I am the only person using Centrify cloud that would like to manage Azure AD users. If it turns out that there's not an easy way to do it, I am going to have to separate O365 from Centrify I think.

 

Thanks again

Contributor I
Posts: 16
Registered: ‎03-26-2017
#4 of 6 2,765

Re: Windows 10 sign in with azure AD not working

So, any additional advice or guidance you can offer?

Centrify Guru I
Posts: 2,295
Registered: ‎07-26-2012
#5 of 6 2,753

Re: Windows 10 sign in with azure AD not working

@Cory,

 

Sure.  Happy to help.  I'm sorry I did not reply earlier (buussssyyy...!)

 

In summary:  What you want to accomplish, right now, can't be done unless your Windows 10 clients are domain-joined (note, this is not our limitation - like you stated, certain capabilities related to the services you mention, are designed/work better if an on-premises AD is in play). 

However we are working hard to make this happen relatively soon because you're not alone.  Smiley Happy

 

But, let's dissect your approach here.  You maybe adding some complexities.  After we dissect this, I'll offer you a short term alternative.

 

Now, as far as Windows goes, my requirements are a little bit different. I don't specifically want users to sign in with Centrify, nor do I need MFA at the login screen.

 

Okay, this is good to know. 

 

The only reason I'm trying to get Win10 sign-in with Centrify working is because my Office 365 users are provisioned by Centrify, and what I really want is for users to be able to sign into Windows with their office 365 accounts to get SSO for all the integrated services like Office apps, onedrive for business, sharepoint, etc.

 

OK, so what you want is to have "identity consolidation" when signing-in to the Windows 10 system and making this happen using Office365 as the directory of record. 
There are technical reasons that impair us from doing this today, hence the requirement that your users log in with an Active Directory account (on premises or hosted a'la AWS Microsoft AD or Azure Active Directory Domain Services), but we should have a solution for this scenario soon.

 

I think your requirement can be solved (partially) by simply having your users log in "any way they want"  (local account, Windows Hello, etc) and when they launch the browser, they can be prompted to authenticate to the Centrify portal, from that point on, they'll enjoy SSO to all their apps.  You could even enhance this by providing the Zero Sign-on experience as well.

 

As a secondary requirement, I want to use Azure AD to manage policy on my domain joined devices, essentially replacing a real on-prem AD with Azure AD (and maybe Intune if I need it). If it's also possible to somehow get SSO for my other web apps that use Centrify, using the windows login credentials, that would be a huge bonus, but it's not a show stopper if not.

 

 

Here, I'd really like understand what policies are a must have for you vs. what are a nice to have.  This is in the works for us in a project, but ideally getting feedback for your plans, that would be great.

Interestingly enough, does that mean that you have an on-premises AD that we can leverage?  If that's the case, that simplifies a lot.  Note that with our Apps service, you don't need ADFS/DirSync or any of the new improvements MSFT has made.

 

So my "problem" at the moment is that I have joined my laptop to Azure AD, I can see it under devices in the Azure AD console, but I cannot log into Windows with my Office 365 (centrify) credentials. When I try to log into Windows using my office 365 user (i.e. cory@myo365comain.com) and I enter my Centrify password, it seems like it does make a remote call of some kind because it thinks about it for a few seconds, but then I get a "incorrect username of password" error.

 

I think I may have explained this in my previous post, but it did not come across. 

You can't log in to the Windows system with your o365 credentials unless the system belongs to an Active Directory domain that is used as the identity source for your office365.  This is not a Centrify limitation.  We are working on overcoming this in the medium term.

 

The technical reason is this - Windows systems need to belong to a "realm" and a trust-relationship between the system and the source of authentication (like  a Kerberos realm) need to be established.  So when a user logs in (and I'm over-simplifying this) there are assurance mechanisms that establish the confidentiality of the channel and that the authenticating server is the right one (not an impostor) - hence the need for an Active Directory environment.   Windows 10 systems have the ability to use other realms as the source of the microsoft account (for example, your gmail account), but that won't give you enterprise capabilities like policy enforcement or access to resources over the network.

 

I think these are the relevant parts of the post.

 

So let's consolidate your requirements (and this is all without having an on premises or hosted AD):

a) Log in to a Windows 10 system with the O365/Azure AD identity FROM Anywhere
Nice to have identity assurance here and that option will be available.

b) Be able to get SSO to the Centrify portal and SSO-aware apps.

c) Be able to enforce policy (we need to know what policies are important).

We are very much working towards that.  To also improve here, you should be able to do this, regardless if you have O365 or not (maybe you're a Google Apps shop).  Because if a single provider like Centrify can do all this, many SMB to mid-size companies will be interested.

 

What can you do today:

All of the above, as long as your system is Domain-joined.  In the policy side we leverage AD GPs.

 

Please reply with your reaction.

Want to learn more about practical Centrify examples? Check out my blog at http://centrifying.blogspot.com
Follow Centrify:
Contributor I
Posts: 16
Registered: ‎03-26-2017
#6 of 6 2,699

Re: Windows 10 sign in with azure AD not working

Thanks again for your very detailed reply, I appreciate that you're busy, but this is literally the only place I've found I can get good help with Centrify.

 

Your suggestion about having users log into windows locally then authenticating in browser with Centrify portal is pretty much what I've got now, with the addition that I've also managed to get sign in with most office 365 desktop apps working via th Centrify SAML redirect page as well - the exception being skype for business, but when I looked into what was required it just looked like too much hassle.

 

Unfortunately I'm not really happy with this because it still requires too much interaction on the user's part, and the user experience with office apps is not great. This is why I want to move to pure o365/AAD logins, because then once a user logs in, they get auto sign in for one drive, sharepoint, outlook, skype, and even the office web apps with IE or the right chrome plugins. I want to be able to give a user a new laptop that, have them sign in and join the AAD domain with the OOB experience, and then presto they get access to all their cloud services - microsoft-wise anyway.

 

In terms of policies that I want, must haves are basically anything security related: enforce windows update, AV, bitlocker, windows firewall, find my device, remote wipe, disable local admin access, etc. Basically all the things you would do when managing a domain joined PC, at least in as far as what you can accomplish with AAD (+Intune, maybe).

 

On Friday I attended a workshop on O365 security, and what I took away from it was that microsoft stuff works best with other microsoft stuff. When I asked the instructor about using federated users from a 3rd party foreign directory, he basically told me I was an idiot for even trying. Microsoft doesn't intend for AAD and Windows 10 to work that way, and if I want to use all the good stuff that comes with Microsoft 365 business, like ATP and DLP, AAD joined devices and logins are the only way to go.

 

Thanks very much for clarifying that what I'm trying to achieve won't work today without an onprem AD. No, I don't have one, nor do I want the overhead of managing a hosted one in AWS or something. Now I at least know that the only real option here is to separate my microsoft services from centrify, and TBH I was kind of leaning this way anyway

after the last few days because I've come to the conclustion that as nice as being able to manage all my user accounts in one place is, the integration between centrify cloud and AAD just adds too much complexity. I will probably just stick with Centrify for my other apps and leave MS in it's own little bubble.

 

FWIW, I think the fact that Centrify cloud relies on WS-Fed to integrate with Office 365 is the real problem here. If Centify could hook into AAD with real AAD-Connect, and use Azure AD as the source directory the way Centrify on-prem works, then there would be a much better chance of all this working the way I want it to.

 

Thanks again for taking the time to explain the situation here, I really appreciate it.