OWA 365 login problem

[OxMB]

On our site we have a small number of people who use non-domain laptops. (There is a particular background to this, these are supplied from outside and this is unlikely to change.)

 

In most cases accessing OWA 365 webmail (we have just gone over to 365) is not a problem. However in a couple of cases you get:

 

"Sorry but we're having trouble signing you in". Error 80041317.

 

Now according to Microsoft's articles, and a lot of ADFS advice (we have recently started using ADFS), this error relates to federation problems. HOWEVER in this case there is merely a problem ON THAT PARTICULAR USER OF THE NON-DOMAIN LAPTOP. The domain user itself does not have a problem if, for example, they use exactly the same approach but just on a different user on the same non-domain laptop. So I would conclude that the problem is on the non-domain laptop.

 

I have tried clearing everything I can think of in Internet Explorer (please suggest anything I may have missed) and also clearing the credentials vault (I think, again if there's a heavier duty way of doing it, or I may have missed something please let me know).

 

It does prompt for login details in the little 'Windows Security' pop-up. However you then go through to the 80041317 page. What is Windows storing, and where is it storing it that is causing this problem, or what do you think could be going on?

 

In summary: no domain users can sign in from that local laptop account, they can all sign in from a different local account on the same laptop.

Edited March 3, 2014 by OxMB

[sted]

try running ie in inprivate mode. I have 1 pc in a school where it wont work in normal mode but works fine in inprivate for some daft reason

[OxMB]

Yes it does work using InPrivate mode. That only reinforces my view that it has cached something erroneous that it will attempt to use in normal mode but not in InPrivate mode.

 

Does anyone have any idea why InPrivate mode would help (once again I must emphasise FOR SPECIFIC USERS OF A NON-DOMAIN LAPTOP ONLY all other scenarios don't have the problem - other local users on that laptop are fine).

[Michael]

What about if you set IE to delete the user cache on closing the browser? This should have the same results.

 

Alternatively use a different browser.

 

Out of curiosity, are these users logging in using the same Office 365 school domain or a separate Office 365 school domain to everyone else?

[OxMB]

Michael - same Office 365 domain as everyone else.

 

Please note carefully what I have posted. I am making a very careful distinction between domain users on the one hand, and local laptop accounts on the other hand. The problem has NO CORRELATION to the domain user attempting sign in, BUT COMPLETE correlation to the local laptop account used.

[EduTech]

Michael - same Office 365 domain as everyone else.

 

Please note carefully what I have posted. I am making a very careful distinction between domain users on the one hand, and local laptop accounts on the other hand. The problem has NO CORRELATION to the domain user attempting sign in, BUT COMPLETE correlation to the local laptop account used.

 

Hi,

 

Are you using AD FS for authentication? If this is the case then you will find that when you are using a Domain Joined machine that you will most likely be passing through your LOGGED ON Credentials to Office 365, AD FS will be using Integrated Authentication.

 

If you require further assistance please open a Support Case to further investigate this issue so the correct questions can be asked and answers obtained outside of the Public Domain.

 

Many Thanks,

James.

[OxMB]

James,

 

Yes we are using ADFS for replication.

 

Yes, I am well aware that using a domain joined machine then logged on credentials will be passed through.

 

What you are missing is that I have clearly stated that on most of the NON-DOMAIN JOINED machines the 'Windows Security' box prompts for credentials AND THESE ARE ACCEPTED AND THE USER IS TAKEN THROUGH TO WHERE THEY SHOULD BE. It is only SOME LOCAL ACCOUNTS on some non-domain laptops, and even there InPrivate browsing makes the problem go away. InPrivate browsing is not a full solution, obviously.

 

How can I seek support? I imagine we would have to pay for this?

[OxMB]

Michael,

 

You mentioned using a different browser. For specific reasons the users concerned would rather not do that. But yes other browser do work. The user cache is already set to clear on exit, and this has been manually cleared, and so has the credentials vault to no effect.

 

When using IE the 'Windows Security' pop-up comes up. In other browsers what happens is different and you get taken through to a login page. Is this because Internet Explorer supports NTLM? Is that what happens? There is clearly a different process on a non-domain computer (as there is on a domain computer) when using IE versus other browsers. Yes we are using ADFS, but surely that cannot be coming into play on non-domain computers?

[EduTech]

James,

 

Yes we are using ADFS for replication.

 

Yes, I am well aware that using a domain joined machine then logged on credentials will be passed through.

 

What you are missing is that I have clearly stated that on most of the NON-DOMAIN JOINED machines the 'Windows Security' box prompts for credentials AND THESE ARE ACCEPTED AND THE USER IS TAKEN THROUGH TO WHERE THEY SHOULD BE. It is only SOME LOCAL ACCOUNTS on some non-domain laptops, and even there InPrivate browsing makes the problem go away. InPrivate browsing is not a full solution, obviously.

 

How can I seek support? I imagine we would have to pay for this?

 

Hi,

 

If you have an Office 365 Subscription than you are entitled to FREE support and you can raise a support request via the Administration Portal. Login as a Global Admin > Support Requests > New Support Request.

 

I would want to run some traces in order to obtain further information, because the event ID that you have raised above is a generic event ID and can be caused due to a few things.

 

It sounds like a SAML token is being sent to Office 365 from AD FS when you attempt to login, and something contained within that is invalid which is causing the event to be logged. If I can obtain some traces, I can see what was sent in the token and then we can work out if it was even valid and then if it was not, it will give us the information required to identify where the issue maybe.

 

Regards,

James.

[OxMB]

James,

 

Thanks for the clarification about Office 365 support. I had asked my boss whether we had support available, but he gave me the wrong answer initially because he was confused with Office 2013 support.

 

My boss has informed me that he has been through this support before. Initially he dealt with Microsoft first line. He says it was VERY painful. EVENTUALLY he was put through to 2nd line support in the UK, at which point his issue was dealt with very quickly. This makes me very apprehensive because I don't have a long time to jump through hoops with first line.

[EduTech]

James,

 

Thanks for the clarification about Office 365 support. I had asked my boss whether we had support available, but he gave me the wrong answer initially because he was confused with Office 2013 support.

 

My boss has informed me that he has been through this support before. Initially he dealt with Microsoft first line. He says it was VERY painful. EVENTUALLY he was put through to 2nd line support in the UK, at which point his issue was dealt with very quickly. This makes me very apprehensive because I don't have a long time to jump through hoops with first line.

 

Hi,

 

I appreciate your feedback in regards to your experience with the Front Line support and I am more than happy to discuss this with you further. In terms of resolving your issue, I have sent you a PM and hopefully we can get this sorted for you.

 

James.

[OxMB]

Just to let everyone know, we have now resolved this issue. Microsoft had a long queue, and they said they would get back to me. They did this by email using the wrong account (which was mainly my fault, a misunderstanding), although I was definitely expecting them to get back by phone. They eventually did this after a day and half.

 

Microsoft first line (once I was actually talking to them) were better for me than they were for my boss. They pointed to likely user profile issues (local laptop users profiles), and they were right. I must admit I don't have the same instinct to go for user profile issues on non-domain devices as a I do within the domain scenario.

 

Users in question had folders on c:\users which weren't named correctly, and may have had bad permissions. I recreated the affected users, copying work across. After that OWA 365 allowed a perfectly fine Internet Explorer based login.

 

Is there something I should do to flag this as resolved?