Azure AD SSO still prompts for password while on a domain joined computer

[CUrti300]

Hey I was wondering if anyone has ran into a similar issue that we are running into here. While testing with a browser we are getting a prompted for a password while on a domain joined computer

We currently have AAD Connect setup with SSO and domain is managed not federated and we also have Hybrid Join setup and that process seems to be working once  a computer is hybrid join we are able to authenticate with the token. We are trying to get other piece working.

So far during my testing of a computer that is domain joined only and is not in azure ad. We are using a web browser to test.

1. I have verified we have the trust sites added which are..

https://aadg.windows.net.nsatc.net

https://autologon.microsoftazuread-sso.com

2. I've verified we are getting a ticket from the azureadssoacc by doing a wireshark and doing a manual klist get azureadssoacc and purge

3. I've tested with IE in unprotected mode but still get prompted to enter a password.

4. When we run the microsoft connectivity anaylzer we get the "domain is not federated" error does that apply to us since its a managed domain within azure ad?

is there anything else I should check? Thanks in advance.

[#2]

Check in internet explorer options under sites or trusted I can’t remember but in the zones you pick the one internet sites fall in and in the options list towards the bottom is the “login using local domain username and password” make sure that’s on and see if it helps. It’s been a long time since I set that but pretty sure that’s one that will pass the creds through.

[#3]

@Chris Webb 

I did try this but no luck I did find out that the error 403 was referring to a link and when clicking on the link its giving us a AADSTS81004 Kerberos Authentication Failed.

I did see some articles referencing a security baseline and tried setting the network security policy to not defined but no luck.

[#4]

I wanted to give an update - I did end up fixing this.

 I think the Decryption/Encryption Key that is stored in Azure AD was using the RC4_HMAC_MD5 Cipher. Which explains why we are seeing a 403 since we are sending an ticket over with AES Encryption. Since we haven't rolled it over since 4/2019

1. I believe according to the comments this was recently updated to support the other Ciphers - https://feedback.azure.com/forums/169401-azure-active-directory/suggestions/36121711-add-support-for...

So after we rolled over the key this weekend (which I know is recommended every 30 days) The Seamless Single Sign-on started working. I'm not sure if this had anything to do with it being past the 30 days but I've marked it on my calendar to see if it still works after 30 days.