You’re offline. This is a read only version of the page.
5
Hi there,
I successfully installed Dynamics CRM 9.1 on-premises (No Claim-based authentication nor IFD is configured) and discovered the below behaviors if I started a browser and navigate to:
Scenario 1: http://localhost
[Result: Auto logged in to the CRM, not prompting for username and password]
Scenario 2: http://hostname.xxx.com (Where xxx.com is the Active Directory domain)
[Result: Auto logged in to the CRM, not prompting for username and password]
Scenario 3: http://crm.yyy.com (Where crm.yyy.com is a random custom URL, I simply created an entry in the host file in the server, pointing crm.yyy.com to the IP address of the server)
[Result: Prompting for username and password. Need to provide the username and password to log in to the CRM]
From my perspective, I think Scenario 2 & 3 should result the same, i.e. auto log in the crm without the need to manually enter the credentials. May I know if you have any idea on this behavior? Thanks.
Hi Philip,
Sorry the getting back late.
Thank you so much and I think the solution you provided is exactly what I need. Tested in my environment and it seems working perfectly!
Best regards,
Ivan
Hi Ivan.
Mm, I asked because I couldn't tell from your original post, but yeah, I expected it wasn't working because of missing SPN's which will fail Kerberos auth.
I found the following article that explain the bits and pieces needed when setting it up with IIS.
https://techcommunity.microsoft.com/t5/iis-support-blog/setting-up-kerberos-authentication-for-a-website-in-iis/ba-p/347882
As an addition to the article above i would always suggest using "setspn -s" instead of -a as it will check prior to adding if there is already an identical SPN configured in the domain, and you definitely don't want an duplicate.
For more in-depth there is tons of them out there by just searching "Kerberos autentication" but you usually won't have to go that far if your not working with complex domain and network configurations.
And lastly..
Never alter or delete pre-existing SPN's like the ones for the computer account object.
Good luck!
Best regards
Philip
Hi Philip,
Really appreciate for the information and tips! Will try your suggestion to see if it works.
Regarding "Out of curiosity, were/are you able to sign in via http://crm.yyy.com prior to adding it to Local Intranet?", the answer is no. I am not able to sign in the CRM. I think it's because of the Kerberos authentication is failing like you said?
BTW, may I know if you have any suggested links or articles about the concept/elaboration on the 4 steps you provided. It is definitely detailed enough for me to proceed the test, however, I am also eager to understand on this issue. It would be great if you can share me some information on this. Thanks.
Best regards,
Ivan
Hi again Ivan.
Out of curiosity, were/are you able to sign in via http://crm.yyy.com prior to adding it to Local Intranet?
The issue with repeated login prompts even thou providing correct credentials followed by a 401.1 is typically because Kerberos authentication is failing.
To resolve this you will need to add the SPN(service principal name) to either the hostname(computer object) or the service account used for "CRMAppPool" in IIS(Identity) depending on if you have set UseAppPoolCredential=True in configuration editor on the Microsoft Dynamics CRM website.
I will assume you have not, so in order.
1. Check CRMAppPool Identity
2. Register the SPN to the identity which depending on permissions on the user-object in AD you might not have and need to request it been done by your domain administrators:
With the correct permissions you would run the following in command prompt(replace with your real values ofc):
setspn -s HTTP/crm.yyy.com <identity>
3. In IIS configuration(system.webServer/security/authentication/windowsAuthentication) for Microsoft Dynamics CRM website, set UseAppPoolCredential to True.
4. Do an IISRESET or restart the CRMAppPool
This should resolve the issue.
One note thou: If you are testing locally from the server you will also either need to disable loopback check entirely or specifically for the custom fqdn e.g. crm.yyy.com with BackConnectionHostnames registry entry.
Old MS article but still valid:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/accessing-server-locally-with-fqdn-cname-alias-denied
Regarding using claims-based authentication it's of course the only valid option if you plan to expose CRM for external access(internet) with IFD, but it's not necessary if you only want the users on the internal network to be able to access it without having to provide the credentials.
With that said, if you already have ADFS setup in the domain, go for it!
Hope this helps.
BR. /Philip
Hi Philip,
First of all, thanks for the explanation.
Based on your description, I further did some tests on Scenario 3 using http://crm.yyy.com custom domain. It turned out that no matter I added this custom domain to Security > Local intranet or Security > Trusted sites under Internet Options, a prompt would still pop up for username and password, and even I entered the correct AD username and password, it would not sign me in and ask me for the password again. After trying it for three times, it returned a 401.1 error. (I am 100% sure the AD username and password is correct).
This leads me to think that if accessing the CRM using a domain that CRM considered as Internet zone/External, the only way to allow users to sign in using their AD credentials is by configuring Claim-based authentication?
If the requirement needs to auto sign in, then we need to integrate with AD FS?
Hope my questions are clear and it would be great if you can share your opinion regarding these. Thanks a lot.
Best regards,
Ivan
Hi!
http://localhost or just http://<yourhostname> is by default treated as Intranet zone in your browser which will have "Automatic sign-in for intranet zone"
It's common that IT-admins add a wildcard for the local domain, e.g. in your example *.xxx.com to this zone via Group policy hence why it would sign you in automatically browsing to http://hostname.xxx.com
However, in this case you've added a local entry with another domain "yyy.com" that instead is treated as an Internet zone which do not automatically sign you in as default.
So via Internet options on the client(pc) check Internet options - Security tab - Local Intranet(zone) and then Sites to see if this is the case.
Best regards.
Philip
It would be great if someone can shed some light on this, thanks.
Stay up to date on forum activity by subscribing. You can also customize your in-app and email Notification settings across all subscriptions.
#1
André Arnaud de Cal...
291,253
Super User 2024 Season 2
#2
Martin Dráb
230,188
Most Valuable Professional
#3
nmaenpaa
101,156
Share
Report
All responses (
Answers (