e-matters
asked on
How can associate external FQDN with internal FQDN to prevent logon popup?
Hi,
We've developed our corporate intranet in MOSS on Windows 2003 and linked it to our active directory so that if you enter https://portal.ourcompany.local from the LAN, you get through to the MOSS intranet, and are logged in to the portal automatically because we are logged in to our desktops.
Through MOSS, we have changed the FQDN of the intranet to https://portal.ourcompany.com so that those out on the road can access it. Works fine externally with a logon popup shown for the user, but internally on the LAN where people log onto the ourcompany.local domain through active directory we'd still like them to be able to log in to https://portal.ourcompany.com without getting the popup box.
By entering their details again they are taken to the portal but we'd like to omit this additional prompt. The DNS records have been changed so that someone on the LAN gets portal.proctorgroup.com resolving locally to the MOSS server.
How can we get rid of the additional login prompt for local LAN users?
Cheers,
Jim.
We've developed our corporate intranet in MOSS on Windows 2003 and linked it to our active directory so that if you enter https://portal.ourcompany.local from the LAN, you get through to the MOSS intranet, and are logged in to the portal automatically because we are logged in to our desktops.
Through MOSS, we have changed the FQDN of the intranet to https://portal.ourcompany.com so that those out on the road can access it. Works fine externally with a logon popup shown for the user, but internally on the LAN where people log onto the ourcompany.local domain through active directory we'd still like them to be able to log in to https://portal.ourcompany.com without getting the popup box.
By entering their details again they are taken to the portal but we'd like to omit this additional prompt. The DNS records have been changed so that someone on the LAN gets portal.proctorgroup.com resolving locally to the MOSS server.
How can we get rid of the additional login prompt for local LAN users?
Cheers,
Jim.
Both domains need to be in AD and then set up a trust between the domains so that the portal domain will trust the internal.
I believe that adding the https://portal.ourcompany.com address to your Local Intranet "Sites" list in your browser would fix that issue. This would be (in IE7) in Internet Options, on the Security Tab, in the Intranet Zone. Click Sites, then Advanced, and you should be able to add it. The problem is that the browser will not pass Authenticated credentials to a non-trusted location (ie the Internet), and it cannot tell that your ".com" address is really an internal trusted location. You can update this via the registry as well (see code)
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\ourcompany.com\portal]
"*"=dword:00000001
ASKER
Hi,
I had already tried this but still received the pop-up.
Best regards,
Jim.
I had already tried this but still received the pop-up.
Best regards,
Jim.
ASKER
Hi,
Thanks for your response. Is it possible to set up the ourcompany.com domain name without having a domain controller for it, by simply adding it as a record into DNS or something similar?
Thanks for your response. Is it possible to set up the ourcompany.com domain name without having a domain controller for it, by simply adding it as a record into DNS or something similar?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
And then it is straightforward to get the two domains to trust each other?
Trust is an AD term for allowing two Active Directory's to "trust" each others' (two-way or one-way) authentication. This means that DomainA\User1 can be given access to DomainB\Server1's fileshares, even yought they are not part of the same AD Forest.
DNS Domains have no need of such a trust, as they are resolution only resources. They resolve names to IPs, no security involved.
DNS Domains have no need of such a trust, as they are resolution only resources. They resolve names to IPs, no security involved.
ASKER
Sorry to be thick, but if I need to establish a trust then presumably I need to Active Directories. At the moment I have one, and an external domain name. I guess one alternative is to set up a barebones server with an Active Directory for ourcompany.com and then trust them, but I'd rather there was a cleaner way.
If you have the DNS domain resolving correctly, and you are importing the profiles and security from the correct AD structure, there should not be an issue. Are you sure you need a matching AD domain for the external DNS name? I would not think this would be necessary. If your PC's are in the same Domain as your profiles, and you are logging in to that same AD, and your IE client recognizes the URL as a trusted internal site, your credentials should be passed to the MOSS servers... If some point along that chain fails, then you will be prompted.
I am having this exact same problem, but feeling sort of ignorant. My internal and external domain are the same? What am I missing?