Access to Microsoft CRM 4 through ISA 2006
I have a CRM 4 installation in my domain and things runs just fine. Now I need users outside the domain to be able to access the CRM from the Internet, so I have setup a ISA 2006 to serve this issue.
I have followed the instruction described in this blog: http://blogs.technet.com/isablog/archive/2008/07/23/publishing-microsoft-crm-4-0-through-isa-server-2006.aspx
Internet users get the CRM login page, but when they try to login with their domain user the page just says "wrong username/password" or just reloads.
Nothing is logged on the domain controllers (logon failure). If I type a username that don't exist in the domain I can see this in the event log on the DCs (meaning the login page do send the credential to the DCs).
I have published Sharepoint through the ISA and that works like a charm.
Anyone have any ideas or experience with CRM and ISA?
SG
I have followed the instruction described in this blog: http://blogs.technet.com/isablog/archive/2008/07/23/publishing-microsoft-crm-4-0-through-isa-server-2006.aspx
Internet users get the CRM login page, but when they try to login with their domain user the page just says "wrong username/password" or just reloads.
Nothing is logged on the domain controllers (logon failure). If I type a username that don't exist in the domain I can see this in the event log on the DCs (meaning the login page do send the credential to the DCs).
I have published Sharepoint through the ISA and that works like a charm.
Anyone have any ideas or experience with CRM and ISA?
SG
ASKER
hi!
Yes I'm using domain\username (tried username@upn and just "username").
The IFD is already up and running.
I've got some screenshots from a MS CRM partner of their ISA and IFD setup. I'll look into that tomorrow and see if I can spot some misconfiguration.
SG
Yes I'm using domain\username (tried username@upn and just "username").
The IFD is already up and running.
I've got some screenshots from a MS CRM partner of their ISA and IFD setup. I'll look into that tomorrow and see if I can spot some misconfiguration.
SG
A few other things to consider/test:
* I've always heard war stories about ISA. Do you really need to utilize this for security of the server?
* It's very strange that SharePoint and your login page both get through without a problem - but a proper password is neither allowing you in nor generating an entry. Is it possible that your outside users are not recorded correctly in your Active Directory - or that you have not added them as users to CRM along with a Security Role?
* I've always heard war stories about ISA. Do you really need to utilize this for security of the server?
* It's very strange that SharePoint and your login page both get through without a problem - but a proper password is neither allowing you in nor generating an entry. Is it possible that your outside users are not recorded correctly in your Active Directory - or that you have not added them as users to CRM along with a Security Role?
ASKER
The main difference with Sharepoint and CRM from the ISA view, is that with SP users authenticate towards the ISA but with CRM the users authenticate towards the IFD (CRM site).
ISA is just a tunnel and firewall in a DMZ for CRM (like described in the blog above).
SG
ISA is just a tunnel and firewall in a DMZ for CRM (like described in the blog above).
SG
That makes sense.
Did you check to see if the users who are logging in to CRM via the IFD are setup as CRM users and have a Security Role in CRM?
Did you check to see if the users who are logging in to CRM via the IFD are setup as CRM users and have a Security Role in CRM?
A few other suggestions:
(1) Add the IFD URL to the Trusted Sites in IE (NOT the Intranet Zone). Restart your browser and re-test.
(2) When logging out of the IFD, always make sure you use the logout button (don't just close the browser). This way, cookies will be "cleaned up" appropriately. If in doubt, try to delete all of your Internet files and try logging in again.
(3) You can also set outlook to authenticate to the IFD ... which means your users should not need to login when opening CRM.
(4) On the CRM server, check the web.config file. The external setting should be for anonymous access for outside and authenticated access for inside.
See if any of the above resolves your problem.
(1) Add the IFD URL to the Trusted Sites in IE (NOT the Intranet Zone). Restart your browser and re-test.
(2) When logging out of the IFD, always make sure you use the logout button (don't just close the browser). This way, cookies will be "cleaned up" appropriately. If in doubt, try to delete all of your Internet files and try logging in again.
(3) You can also set outlook to authenticate to the IFD ... which means your users should not need to login when opening CRM.
(4) On the CRM server, check the web.config file. The external setting should be for anonymous access for outside and authenticated access for inside.
See if any of the above resolves your problem.
ASKER
I kinda think I found the problem. Please have a look at the attached ss (taken from the above blog).
Our domain is named (I'll just put in contoso as the domain name) "contoso.internal" with AD integraded DNS, while on the outside we have "contoso.com" on the external DNS.
The CRM server is part of the domain and uses the internal DNS. When I set the "IFD App Root Domain" to "contoso.internal" it resolves correct (tools -> Check DNS ). But this can't be resolved from the outside. If I understand the documentation correct the "IFD App Root Domain" should be the name that external users uses. If I set it to "contoso.com" the "Check DNS" failes.
I'm postive there must be a solution to this case since it's very common to have "domain.local/internal" used. Any ideas?
SG
ifd.jpg
Our domain is named (I'll just put in contoso as the domain name) "contoso.internal" with AD integraded DNS, while on the outside we have "contoso.com" on the external DNS.
The CRM server is part of the domain and uses the internal DNS. When I set the "IFD App Root Domain" to "contoso.internal" it resolves correct (tools -> Check DNS ). But this can't be resolved from the outside. If I understand the documentation correct the "IFD App Root Domain" should be the name that external users uses. If I set it to "contoso.com" the "Check DNS" failes.
I'm postive there must be a solution to this case since it's very common to have "domain.local/internal" used. Any ideas?
SG
ifd.jpg
Hmm...sounds like an issue with pointing to the new domain from the Internet. Can you just go to your registrar (i.e. godaddy.com, network solutions, etc) and set the pointer for the appropriate domain to your IP address?
We had to point crm.OURDOMAIN.com to our IP address from GoDaddy and then setup the site correctly. Let me know if you need more detail and I can probably find something for you.
We had to point crm.OURDOMAIN.com to our IP address from GoDaddy and then setup the site correctly. Let me know if you need more detail and I can probably find something for you.
ASKER
I have full access to both the internal and external DNS.
I have done this:
Created a A-record on the external DNS: "something.contoso.com" -> <IP of the ISA>
The ISA server publising rule sends the request to "crm.contoso.internal" (the ISA server uses internal DNS and should not authenticate like they do in the blog. Just let the IDF do the authentication job).
Created a A-record on the internal DNS: "crm.contoso.internal" -> <IP of the CRM server>
When I test to go to our CRM from the outside with IE: "http://something.contoso.com" I'm pass to the IDF and it appends this to the URL. It looks like this:
http://something.contoso.com/signin.aspx?targeturl=http%3a%2f%2fcrm.contoso.internl%3a5560%2fdefault.aspx
So my guess is that the credential should be sendt to the "target url" defined in the URL string, but since "something.contoso.com" is unknown inside the domain it stops. The CRM server do not recognize "something.contoso.com".
Please advice if you got an idea. I'm seeing myself blind on this issue :(
SG
I have done this:
Created a A-record on the external DNS: "something.contoso.com" -> <IP of the ISA>
The ISA server publising rule sends the request to "crm.contoso.internal" (the ISA server uses internal DNS and should not authenticate like they do in the blog. Just let the IDF do the authentication job).
Created a A-record on the internal DNS: "crm.contoso.internal" -> <IP of the CRM server>
When I test to go to our CRM from the outside with IE: "http://something.contoso.com" I'm pass to the IDF and it appends this to the URL. It looks like this:
http://something.contoso.com/signin.aspx?targeturl=http%3a%2f%2fcrm.contoso.internl%3a5560%2fdefault.aspx
So my guess is that the credential should be sendt to the "target url" defined in the URL string, but since "something.contoso.com" is unknown inside the domain it stops. The CRM server do not recognize "something.contoso.com".
Please advice if you got an idea. I'm seeing myself blind on this issue :(
SG
ASKER
Btw. the CRM server can resolve "something.contoso.com" by DNS forwarding, but it seems like the ISF don't support DNS forwarding.
Looks like you need to set up your internal DNS so that http://something.contoso.com resolves correctly INSIDE your network.
ASKER
That was a scenario I did hope to avoid. If I add the "contoso.com" as a forward lookup zone in the internal DNS will mean I will have to both update internal- and external DNS when I do modify the zone.
Do you have a CRM installation with ISA and IDF installed? If so is your internal domain in a ".internal/local" form?
Do you have a CRM installation with ISA and IDF installed? If so is your internal domain in a ".internal/local" form?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
It's working now :)
I moved the zone inside my domain and I'm now running split DNS. That did the trick.
I totally overlooked this statement in the blog, so thanks for pointing it out!
Cheers!
I moved the zone inside my domain and I'm now running split DNS. That did the trick.
I totally overlooked this statement in the blog, so thanks for pointing it out!
Cheers!
(1) Are your users using the DOMAIN\USERNAME to login? They cannot use just their username.
(2) In addition to the blog, try using the implementation guide as a resource. You'll want to setup an IFD (internet Facing Deployment): http://www.microsoft.com/downloads/details.aspx?FamilyID=1ceb5e01-de9f-48c0-8ce2-51633ebf4714&DisplayLang=en