Looks like the solution in a CNAME config is a wildcard cert. Thomas W Shinder, M.D. Site: www.isaserver.org Blog: http://blogs.isaserver.org/shinder/ Book: http://tinyurl.com/3xqb7 MVP -- Microsoft Firewalls (ISA) > -----Original Message----- > From: isapros-bounce@xxxxxxxxxxxxx > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones > Sent: Monday, October 08, 2007 8:55 AM > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Re: ISA and SAN Certs > > Hmmm...this is not what Steve implied though: > > > This way when Outlook 2007 is on the internet and asks > > joeblow_nameserver for autodiscover.domain.com it will be > > sent to your external DNS entries where it will find > > autodiscover.domain.com which is an alias for > > mail.domain.com, the exact details of why outlook accepts it > > i am not sure, but it doesn't give me any complaints. So this > > way you don't need multiple external IPs (expensive), nor SAN > > SSL certificates (unnecessary and expensive), nor create > > multiple internal websites (unnecessary). > > I was just having a dig around about CNAMEs and SSL as you > guys posted because I was surprised this seems so easy to fix... > > Steve - you got magic certs? :-) > > -----Original Message----- > From: isapros-bounce@xxxxxxxxxxxxx > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison > Sent: 08 October 2007 14:49 > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Re: ISA and SAN Certs > > CNAME works fine for SSL connections *as long as* the > destination certificate includes a name matching the original > FQDN and the client can find it. > For Tom's concern, a mail server with mail.domain.tld in the > cert subject and no SAN would break an > autodiscover.domain.tld connection, but if the cert has a SAN > entry that includes autodiscover.domain.tld (and the client > can find it), the connection will proceed just fine. > > -----Original Message----- > From: isapros-bounce@xxxxxxxxxxxxx > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder > Sent: Monday, October 08, 2007 6:46 AM > To: isapros@xxxxxxxxxxxxx > Subject: [isapros] Re: ISA and SAN Certs > > Actually, CNAME shouldn't work for SSL connections. What name > is the client going to end up using in the SSL session > negotiation when you use CNAME records? > > Thomas W Shinder, M.D. > Site: www.isaserver.org > Blog: http://blogs.isaserver.org/shinder/ > Book: http://tinyurl.com/3xqb7 > MVP -- Microsoft Firewalls (ISA) > > > > > -----Original Message----- > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones > > Sent: Monday, October 08, 2007 8:42 AM > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > Ah, good point...so assuming you are using default ports, the > > CNAME idea sounds like a better option then? > > > > -----Original Message----- > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison > > Sent: 08 October 2007 14:39 > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > Because only a SRV record can describe a protocol and port > > from a DNS query. > > Lots of folks use custom SSL ports and a SRV record is the > > only way it can be found "automagically". > > > > -----Original Message----- > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Steve Moffat > > Sent: Monday, October 08, 2007 6:22 AM > > To: ISAPros Mailing List > > Subject: [isapros] Re: ISA and SAN Certs > > > > Because they didn't know? > > > > :) > > > > Because they never tried it?? > > > > :) > > > > Because they like making things harder than they need tp? > > > > :) > > > > S > > > > -----Original Message----- > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones > > Sent: Monday, October 08, 2007 4:55 AM > > To: ISAPros Mailing List > > Subject: [isapros] Re: ISA and SAN Certs > > > > Ok, now I am confused. If you can simply add a CNAME to > > redirect autodiscover.domain.com to your chosen URL, why did > > the Outlook team bother to create the hotfix to use SRV records??? > > > > -----Original Message----- > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Steve Moffat > > Sent: 06 October 2007 20:51 > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > Just to muddy the waters...:) > > > > I pass this information on, that it may be of help to others > > (including myself in remembering what i did!) > > > > Preamble: This is my setup, so i cannot guarantee that this > > will work for you, I have for this setup, 1 server running > > Windows 2003 x64. If you want to install Exchange 2007 you > > will need it on either Windows 2003 x64 or 2007 x64 bit > > versions, the 32bit (x86) will not work. I also have one > > static public (external) IP. Most of the configurations i > > came across for Exchange will talk about multiple web sites > > (with different internal IPs) the thing they rarely mention > > is that you will need multiple external IPs to map to these > > internal IPs. If you have multiple external IPs then it is > > probably better that you assign 1 for autodiscover.domain.com > > so that you have more choices down the road instead of > > locking it to the same IP as your main CAS IP. If however you > > are restricted to 1 external IP this may help you. > > A little note about SSL certificates, Exchange 2007 is a bit > > of a nightmare for SSL certificates, by default you have a > > self-signed certificate made by exchange, which is ok if you > > have no one accessing any external services like OWA, > > activesync, RPC over HTTP (OutlookAnywhere). However this > > scenario is probably unlikely. If you do have these services > > then you either can install this self-signed certificate on > > every computer that needs to access these services not to > > mention telling people to click through the IE7 stupid "There > > is a problem with this website's security certificate", > > needless to say this is really not a viable option for most > > people. So pretty much the only real option is a commercial > > SSL certificate. Trying to find the most economical way to do > > things, i tried StartCom's free (yes really free, not trial) > > SSL certificate, problem is that it is trusted by almost > > everyone INCEPT Internet Explorer, needless to say it becomes > > a pain to teach people the same thing about untrusted > > certificates. OK - other choices - for Exchange 2007 you are > > talking about 2 SSL (I'll show you the bypass to get it to 1 > > later), one for mail.domain.com and another for > > autodiscover.domain.com, that means if you've done any > > research on the subject that you need an SSL cert that > > supports SAN (Subject Alternative Name). At present the > > cheapest one is $200/year, others are considerably more > > expensive. Better but even $200/year i find a little steep if > > all you need is just a CAS certificate (exchange 2003 > > front-end certs are easily <$100). On top of this you may > > already have a mail.domain.com cert that would now be > > useless. I have a mail.domain.com cert from GoDaddy which > > cost $20/year (or less) and that is the one that i will be using. > > Getting Started: > > To start off I did a clean install of windows 2003 x64, setup > > DNS, WINS (if necessary), DHCP, IIS in that order, a fairly > > typical PDC. Then a standard install of Exchange 2007, there > > a few extra programs and hotfixes to install but the install > > program is good about telling you what you need. A little > > note, you can install the Exchange tools on a 32 bit machine > > to do most of the administration from a client machine. Ok so > > you have a clean Exchange install, let's configure it. > > To allow Exchange to accept connections from other mail > > server, open Exchange Management Shell (EMS) > > Run the following command; > > Set-RecieveConnector -Identity "Default <ServerName>" > > -PermissionGroups "AnonymousUsers" > > Replace <ServerName> with your CAS name. Close the EMS > > To allow Exchange to send mail to other mail servers, open > > Exchange Management Console (EMC), open Organization > > Configuration->Hub Transport, click on 'Send Connectors', > > Right click (RC) in the 'Send Connectors' box and select 'New > > Send Connector', choose a name, for example 'All Outgoing > > Connector', leave the 'Select the intended...' as Custom, for > > the Address Space click the 'Add' button and enter * in the > > Add Address Space window marked Domain, to accept SMTP > > connections from all domains, leave the 'Include all > > subdomains' unchecked. In Network settings leave all values > > at their default settings, in 'Source Server' again leave the > > default values, and finally in 'New Connector' click on 'New' > > to create the connector. > > At this point Exchange should be able to send & receive mail. > > At this point if you are going to support Outlook with RPC > > over HTTP you will need to install that service, go to > > Control Panel->Add/Remove Programs->Add/Remove Windows > > Components, Select Networking Services, click on details, > > click the 'RPC over HTTP Proxy', click 'ok', Click 'next', > > make sure Windows has access to the install source, after the > > proxy is installed, click 'Next'. > > Now you need to remove the Exchange self-signed cert, Open up > > IIS manager (Administrative Tools->Internet Information > > Services (IIS) Manager), Open the Server subfolder, open the > > 'Web Sites' folder, and open the 'Default Web Site', there > > will be several virtual directories (VD) below the DWS > > including owa, and Autodiscover. RC the DWS and select > > Properties, then click the 'Directory Security' tab, then > > click 'Server Certificate' and then click 'Next' at the SSL > > welcome wizard. The next step depends if you already have an > > SSL certificate for mail.domain.com or not. If you do then > > click 'Replace the current certificate' and follow the > > instructions. If you do not have an SSL certificate then > > select the 'Remove the current certificate'. The latter will > > only remove the certificate from the DWS, it will stay in the > > windows certificate store so if you ever need it in the > > future you can always get it back. After you remove the > > certificate, re-run the wizard and it should ask you to go > > through the process of asking for an SSL certificate, follow > > the wizard which will create an certreq.txt file which you > > will need to make the application at a Certification > > Authority (CA) company, such as GoDaddy or others. I will > > leave this to you to follow since the process varies a bit > > from CA to CA (ie for GoDaddy you need to install an > > intermediate certificate, which may not be necessary for more > > expensive CAs. I am using a turbo ssl cert which is > > registered for mail.domain.com and costs $20/year. > > At this point you should have your mail.domain.com cert on > > the DWS, and any other intermediate certs installed. > > Next lets change owa so you need to just enter your username > > and not domain\username; In EMC go to Server > > Configuration->Client Access, RC the owa (DWS) click > > Properties, click the authentication tab, select the 'use > > forms-based authentication:' and then select the 'User name > > only', then click on Browse and choose your logon domain. > > Click 'Ok' to exit. > > To install Outlook Anywhere in EMC go to Server > > Configuration->Client Access, RC the server and select > > 'Enable Outlook Anywhere', for the External host name use: > > mail.domain.com , External authentication methods: choose > > NTLM authentication, do not select 'Allow secure channel > > (SSL) offloading', click Finish to exit. > > Next we need to change the URLs used autodiscover so that all > > services point to mail.domain.com. > > In EMC go to Server Configuration->Client Access choose the > > Offline Address Book (OAB) Distribution tab, RC the OAB (DWS) > > and select properties, Click on the URLs tab and put in: > > https://mail.domain.com/oab for both both internal and > > external URLs. Click 'Ok' to accept and exit. > > Do the same for owa by going to Server Configuration->Client > > Access (Outlook Web Access tab) andRC the owa (DWS) and > > choose properties, on the General tab change the Internal and > > External URLs to: https://mail.domain.com/owa , click > > 'Apply', an extra feature you may want to give is access to > > network shares through owa, this is available on the > > Documents box in owa, if you do then go to the 'Remote File > > Servers' tab and click the 'Configure' button on the bottom, > > enter the domain you are using, ie for mail.domain.com you > > would put domain.com, click 'add' then click 'ok' to exit. > > Then click on the 'Allow' button and enter the FQDN of your > > CAS, ie if the CAS computer name is mx1.domain.com, then > > enter mx1.domain.com and click 'add' then 'ok'. This will > > give owa users access to any network shares that exist on > > mx1. Click 'ok' to save and exit. If you do not want this > > then disregard that previous procedure and click 'ok' to exit. > > Next we'll change the URLs for the Unified Messaging, while > > this step is probably not necessary for most people, it will > > look better at the end. However to change the URLs we need to > > go to the EMS. > > Open the EMS and enter the following command; > > Set-UMVirtualDirectory "UnifiedMessaging (Default Web Site)" > > -InternalURL > > https://mail.domain.com/Unifiedmessaging/Service.asmx > > -ExternalURL https://mail.domain.com/Unifiedmessaging/Service.asmx > > Next we change the URLs of the Availability service which > > will also be the same for OOF, in EMS enter the following command; > > Set-WebServicesVirtualDirectory -Identity "EWS*" -InternalURL > > https://mail.domain.com/EWS/Exchange.asmx -ExternalURL > > https://mail.domain.com/EWS/Exchange.asmx > > Finally we set the autodiscover URL, now this is a little > > special since it is not possible to set the external URL of > > autodiscover. Outlook 2007 is set to look for > > autodiscover.domain.com or domain.com/autodiscover, and this > > is in my opinion where all the security alert mess comes > > from. Anyways in the EMS enter the following command; > > Set-ClientAccessServer -Identity "your CAS server name (ie > > mx1)" -AutoDiscoverServiceInternalUri > > https://mail.domain.com/autodiscover/autodiscover.xml > > Ok all done with EMS, you can close it and go to your DNS > > management, Administrative tools->DNS. First in the Foward > > Lookup Zone (FLZ) for domain.com, RC the domain.com and > > select 'New Host (A)', enter: mail ,for the name and input > > the Internal IP of your CAS. Next RC the FLZ under your > > server and select 'New Zone', click 'Next' at the wizard > > introduction, leave the zone type as Primary and > > ActiveDirectory integrated, click 'Next', leave the zone > > replication on the default, which is to all domain dns > > servers, click 'Next', For the name enter: > > autodiscover.domain.com , click 'Next', for the dynamic > > updates change the setting to 'Allow both unsecure and secure > > dynamic updates, click 'next then click 'Finish'. Now RC the > > new autodiscover.domain.com and select 'New Alias (CNAME)', > > leave the name field blank and just click on the Browse > > button, In the new browse window, double-click (DC) the > > server name, DC the FLZ folder, DC domain.com and then select > > the mail entry, click 'ok' to complete. You can now close DNS. > > I would recommend restarting the server to insure that the > > new settings are accepted. One thing you will want to check > > after the restart is to go to EMC->Server > > Configuration->Mailbox, RC the mailbox database, select > > properties, click on the 'Client Settings' tab and verify > > that you have the 'Default Offline Address Book' listed in > > the Offline address Book window, if not click on the Browse > > button and select it. If it was not there then restart the > > server again after you have selected it. > > Ok almost done! You should be able to start up a Outlook 2007 > > client and when adding an exchange mail account it should use > > the autodiscover feature to get all the URLs. Hopefully > > everything should work, if you do get a Security Alert > > windows then try restarting the client and server, also > > verify that the SSL cert is accepted on the client. If > > everything did go well then Outlook can connect and > > send/receive from exchange. Now you can check that all the > > URLs are pointing to mail.domain.com, while holding down the > > left 'Ctrl' button RC the Outlook icon in the system tray, > > this should give you a menu which has 'Test e-mail > > Autoconfiguration' in the test window, enter your email (ie > > user@xxxxxxxxxx), unselect the "use guesssmart" and "secure > > guesssmart authentication" then click 'Test' > > If everything goes well then you should have 2 sections after > > the results come in, one for Exchange RPC and the other > > Exchange HTTP. The RPC is for LAN connections and HTTP is for > > HTTP connections. In both sections all the URLs should start > > https://mail.domain.com > > If this is not the case then go back and find the problem. > > Another test to do is to verify that your OWA is working > > internally. If you open Internet Explorer (IE) and enter > > https://mail.domain.com/owa , don't forget to change domain > > to whatever your domain is. This should give you the OWA > > login webpage, if not then go back and find the problem. You > > should not have any Security Alerts with the OWA. > > If this is ok then your 200x Outlook clients should be > > working ok internally and your 2003 clients should be ok > > externally. However if you try your Outlook 2007 clients from > > the internet you will probably find that they give a Security > > Alert, and that is because they are looking for either an SSL > > with a name of autodiscover.domain.com or domain.com. Since > > yours is for mail.domain.com it will give a name mismatch > > error. To resolve this you must access your external dns > > entries which are usually handled by your hosting provider. > > For your external DNS you will have a MX record for where > > your mail is sent and probably entries for www, ftp, etc. > > These are the way that computers on the internet find > > domain.com resources. Usually it takes 4 to 24 hours for > > adding or changing the external DNS entries to actually start > > redirecting clients, so don't expect just because you changed > > the MX record that your email will be redirected right away. > > The setup is very similar to the DNS entries for the internal > > network, for the external DNS entries you will have the MX > > record to point to mail.domain.com (MX cannot point to an > > IP), you will need a Host record (A) that is for > > mail.domain.com which points to your external IP and finally > > an Alias (CNAME) entry for autodiscover.domain.com which will > > point to mail.domain.com. > > This way when Outlook 2007 is on the internet and asks > > joeblow_nameserver for autodiscover.domain.com it will be > > sent to your external DNS entries where it will find > > autodiscover.domain.com which is an alias for > > mail.domain.com, the exact details of why outlook accepts it > > i am not sure, but it doesn't give me any complaints. So this > > way you don't need multiple external IPs (expensive), nor SAN > > SSL certificates (unnecessary and expensive), nor create > > multiple internal websites (unnecessary). > > I have been using this for a few weeks now and everything > > appears normal and stable, i have been using Outlook 2007, i > > have not tested this on Outlook 2003 however i do not think > > there should be any problems. The OWA and Outlook clients > > have no problems connecting, the only thing which i find a > > bit un-normal is that it seems to take about 2 minutes for > > Outlook to connect and synchronize, with Exchange 2003 and > > Outlook 2003 it seems to be quite a bit faster, if anyone can > > comment on this I'd appreciate any insight. > > I have tested this also with Windows Mobile 2003SE and the > > activesync works well, if you have the GoDaddy cert you will > > need to add the CA cert to the WM2003 trusted root store, > > then after that it connects fine. > > Most of this information is around the internet but I thought > > this would be useful to write down in one place since i > > didn't find much information about external DNS settings. I > > did leave out some extra information about redirecting the > > OWA URL, which allows users to log into the port 80 http owa > > url and then get redirected to the 443 https url, however i > > am not really satisfied with the current method of the > > redirect html page. If i find something i'll post back. > > Anyways i hope this give some insight for some and will help > > with the installation. > > > > Heh heh...Steve > > > > > > -----Original Message----- > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones > > Sent: Thursday, September 20, 2007 11:16 AM > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > The fact is you just can't be sure, in my book, that makes is > > useless if you want to provide a robust solution and not have > > to worry about use location/infrastucture...anyhow, just > > testing my logic before I decide what to tell customers... > > > > -----Original Message----- > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison > > Sent: 20 September 2007 15:05 > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > That's kinda myopic... > > Your statement suggests that you think all OL clients will be > > found behind CERN or SOCKS proxies. That just ain't true. > > Most folks at home use some CompIsUs $25 toy that barely > > qualifies as a NAT device; much less a firewall or proxy. In > > this case, the SRV record lookup will (may?) work. > > > > > > -----Original Message----- > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones > > Sent: Thursday, September 20, 2007 7:00 AM > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > How about we look at it like this; the SRV solution, in > > reality, is useless! :-P > > > > -----Original Message----- > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison > > Sent: 20 September 2007 14:48 > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > I see what you mean. > > Look at it this way - the benefit for a SRV record in this > > case is to specify a non-standard port if one is required. > > > > -----Original Message----- > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones > > Sent: Thursday, September 20, 2007 3:29 AM > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > From what I can tell, OA looks for the A record first, this > > is the bit that seems silly...especially when combined with > > the issues of SRV and CERN proxies. > > > > Quote from KB: > > > > In this example, the Autodiscover service does the following > > when the client tries to contact the Autodiscover service: > > > > 1. Autodiscover posts to > > https://contoso.com/Autodiscover/Autodiscover.xml. This fails. > > 2. Autodiscover posts to > > https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml > > . This fails. > > 3. Autodiscover performs the following redirect check: > > GET http://autodiscover.contoso.com/Autodiscover/Autodiscover.xml > > This fails. > > 4. Autodiscover uses DNS SRV lookup for > > _autodiscover._tcp.contoso.com, and then "mail.contoso.com" > > is returned. > > 5. Outlook asks permission from the user to continue with > > Autodiscover to post to > > https://mail.contoso.com/autodiscover/autodiscover.xml. > > 6. Autodiscover's POST request is successfully posted to > > https://mail.contoso.com/autodiscover/autodiscover.xml. > > > > The Outlook 2007 "Test E-Mail Auto Configuration" utility > > also follows the same sequence of doing A records first. > > > > JJ > > > > -----Original Message----- > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison > > Sent: 20 September 2007 01:03 > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > Actually, what I'm saying is that if OL 2003/7 is operating > > as a CERN proxy client, it performs absolutely no name > > queries at all; regardless of whether the name is listed as > > an A, SRV, TXT, CNAME, etc. record. This is the basic nature > > of a CERN proxy client; it sends a "gimme this, wouldya?" > > request without regard for how the endpoint might be > > resolved. Thus, OL will never communicate with a DNS server > > in this scenario. > > > > The egress proxy will seek an A record, since there is no way > > for the CERN proxy client to specify how the proxy should > > resolve the destination (it's just not part of the protocol). > > > > You're correct that you have to maintain A as well as SRV > > records if you intend to support CERN proxy as well as > > direct-connected clients. I'm not sure how "silly" this is, > > since CERN proxy mechanisms existed long before OL started > > using autodiscover. AFAIK, OL will seek the SRV record > > first, since this is much more informative than the A record. > > > > Jim > > > > -----Original Message----- > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones > > Sent: Tuesday, September 18, 2007 3:42 PM > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > Hi Jim, > > > > > > > > So, in reality, we are saying that you can never be sure > > Outlook 2007 will work correctly with SRV records if you are > > unsure if the client will ever be working from behind a CERN proxy?? > > > > > > > > This seems a little silly as the SRV check is the last in the > > list, so therefore you will always need an A record for > > autodiscover.domain.com to cater to clients that *may* be > > behind a proxy. If this A record exists, surely Outlook will > > never actually use the SRV record (as it is only used if the > > A record cannot be found) and you still need ISA publishing > > and certs for autodiscover.domain.com to allow for "behind > > proxy" outlook clients... > > > > > > > > As we provide solution for customers, I cannot really afford > > to deploy a solution that may or may not work depending on > > whether the Outlook client is behind a proxy or not. So I > > feel forced to have to go with the A record method > > (reluctantly) to avoid potentially embarrassing questions > > when a CEO cannot get OA to work when at an internet café > > that uses a CERN proxy... > > > > > > > > Am I way off base here or does the logic seem wrong to you??? > > > > > > > > Cheers > > > > > > > > JJ > > > > > > > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison > > Sent: 31 August 2007 15:00 > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > > > > > The problem is that many applications operating behind CERN, > > SOCKS or Socket proxies can't use SRV records. > > > > 1. CERN proxy clients *never* perform name resolution > > for themselves other than to determine if a host is local or > > remote. When it comes time to make the connection, OL (for > > instance), will simple send a "GET > > http://autodiscover.domain.tld/autodiscover.xml"; via its > > local CERN proxy. The proxy assumes that it should resolve > > "autodiscover.domain.tld" using an A record query and > > continues on that basis If all you build is a SRV record, > > this connection will fail. > > > > 2. SOCKS proxy clients *may* self-resolve names; it > > depends on the SOCKS version in use by the application and > > SOCKS proxy. For the record, ISA operates as SOCKS 4.3A, > > meaning that it is capable of performing name resolution on > > behalf of the client. If the application knows that it is > > speaking to a SOCKS4.3a proxy, it will make the connection > > request using the hostname. In this case, the proxy handles > > name resolution in the same way that a CERN proxy does. If > > the SOCKS proxy is operating as SOCKS4 or earlier and the > > application knows this, the application is required to > > perform its own name resolution. > > > > 3. Socket proxy (think FWC) clients will perform name > > resolution as if they had access to the 'Net. How this > > process is handled depends on how the client makes the name > > lookup request. If it (as OL does) makes a Winsock > > GetHostByname or GetAddrInfo call, they don't specify the > > type of record they want, and Winsock (and the Winsock > > LSP/BSP) will send it to the proxy as received. > > > > > > > > IOW, it's a rare case where a proxy-served client will even > > seek; much less receive the SRV record. > > > > > > > > Jim > > > > > > > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder > > Sent: Friday, August 31, 2007 6:42 AM > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > > > > > Hi Jason, > > > > > > > > OK, that makes perfect sense and it's the scenario I'm > > testing today. One listener, one rule for Outlook Anywhere > > and one rule for Autodiscovery, correct? > > > > > > > > So I was right that you can't use the /AutoDiscover path that > > is included in the Outlook Anywhere rule since the Outlook > > Anywhere rule doesn't respond to the public name > > autodiscover.domain.com. The Outlook Autodiscover rule would > > respond to autodiscover.domain.com and forward to the > > /AutoDiscover path. > > > > > > > > The SRV record solution will solve ALL of this complexity > > because it will bypass the need for a second URL and second > > IP address and second certificate. However, its a hotfix that > > you have to call PSS to download and will be included with > > Office 2007 SP1. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > Tom > > > > > > > > Thomas W Shinder, M.D. > > Site: www.isaserver.org <http://www.isaserver.org/> > > Blog: http://blogs.isaserver.org/shinder/ > > Book: http://tinyurl.com/3xqb7 > > MVP -- Microsoft Firewalls (ISA) > > > > > > > > > > > > ________________________________ > > > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones > > Sent: Friday, August 31, 2007 8:15 AM > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > Yep - one listener, two IPs, each IP assigned a > > different SSL cert. > > > > > > > > Not sure if the SRV record will negate the need for > > the autodiscover URL and hence allow us to get away with a > > single SSL cert - have to check this... > > > > > > > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder > > Sent: 31 August 2007 14:13 > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > > > > > Hi Jason, > > > > > > > > One Web listener, but two IP addresses are being used > > by the Web listener, correct? > > > > > > > > Thanks! > > > > Tom > > > > > > > > Thomas W Shinder, M.D. > > Site: www.isaserver.org <http://www.isaserver.org/> > > Blog: http://blogs.isaserver.org/shinder/ > > Book: http://tinyurl.com/3xqb7 > > MVP -- Microsoft Firewalls (ISA) > > > > > > > > > > > > ________________________________ > > > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones > > Sent: Friday, August 31, 2007 6:50 AM > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > Hi Tom, > > > > > > > > Managed to get this working today too, > > although I am using two individual certs on the same external > > web listener. The internal cert on Exchange is SAN'd up and > > ISA publishes everything to the internal cert common name > > irrespective of the public URL. > > > > > > > > The key to most of it working is defining > > correct URLs in Exchange where is defines "External URLs" for > > things like OOF, OAB, EWS etc. > > > > > > > > Now we have all exchange 2k7 services (and > > all the new funky stuff) working externally...had to do a lot > > of it by investigation and cobbling blog entries together, > > not ideal, but go there at last. > > > > > > > > We currently have it working without SRV > > records, but just waiting for the ISP to add these records to > > test if that is a better solution... > > > > > > > > Cheers > > > > > > > > JJ > > > > > > > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder > > Sent: 31 August 2007 00:32 > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > > > > > I'd think that Jim might need to update his > > SAN article. The article implies that ISA doesn't support > > SANs on the Web listener, however I have a guy who has the > > autodiscover FQDN as a second SAN on the certificate bound to > > his Web listener and he's shown me strong evidence that it > > actually works, even though it shouldn't. > > > > > > > > I wish the Exchange or ISA UE teams could get > > it together to explain how to get autodiscovery working > > correctly and more importantly, show us how it works with and > > without DNS SRV records. It looks like once you have DNS SRV > > records, its a no brainer. > > > > > > > > Tom > > > > > > > > Thomas W Shinder, M.D. > > Site: www.isaserver.org <http://www.isaserver.org/> > > Blog: http://blogs.isaserver.org/shinder/ > > Book: http://tinyurl.com/3xqb7 > > MVP -- Microsoft Firewalls (ISA) > > > > > > > > > > > > ________________________________ > > > > From: isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder > > Sent: Wednesday, August 29, 2007 2:38 PM > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA and SAN Certs > > > > Never mind :) > > > > > > > > I found it: > > > > > > > > http://support.microsoft.com/kb/940881 > > > > > > > > Thomas W Shinder, M.D. > > Site: www.isaserver.org > > <http://www.isaserver.org/> > > Blog: http://blogs.isaserver.org/shinder/ > > Book: http://tinyurl.com/3xqb7 > > MVP -- Microsoft Firewalls (ISA) > > > > > > > > > > > > ________________________________ > > > > From: > > isapros-bounce@xxxxxxxxxxxxx > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Thomas W Shinder > > Sent: Wednesday, August 29, > > 2007 2:35 PM > > To: isapros@xxxxxxxxxxxxx > > Subject: [isapros] Re: ISA > > and SAN Certs > > > > OK, that's an interesting > > sentence in a KB OL update article. But there's no mention of > > this anywhere else on the ms.com site. > > > > > > > > In addition, how do we > > configure the SRV records? > > > > > > > > Service? > > > > Protocol? > > > > Priority? > > > > Weight? > > > > Port number? > > > > Host offering this service? > > > > > > > > cid:image001.jpg@01C7F522.ABDB5600 > > > > > > > > I try to read minds best as I > > can, but I'm flailing on this one :)) > > > > > > > > > > > > > > > > Thomas W Shinder, M.D. > > Site: www.isaserver.org > > Blog: > > http://blogs.isaserver.org/shinder/ > > Book: http://tinyurl.com/3xqb7 > > MVP -- Microsoft Firewalls (ISA) > > > > > > > > > -----Original Message----- > > > From: isapros-bounce@xxxxxxxxxxxxx > > > > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison > > > Sent: Wednesday, August 29, > > 2007 2:27 PM > > > To: isapros@xxxxxxxxxxxxx > > > Subject: [isapros] Re: ISA > > and SAN Certs > > > > > > DatzDeWun! O'curse it > > works in real life; I tested it. > > > > > > > > http://support.microsoft.com/kb/939184 > > > OL 2K7 seeks a > > "autodiscovery" SRV record first, and only if > > > that fails, > > > it'll seek the A record. > > This is based on the same domain suffix as > > > specified in the mail domain. > > > If your OL client is behind > > a CERN proxy (and it knows it), it can't > > > specify that the proxy > > should look up a SRV record for > > > autodiscover.sfx. > > > The proxy assumes that any > > CERN request will be for a "host" > > > and makes a > > > DNS query for an A record. > > > > > > OL 2K7 uses the SRV record > > to discover the host > > > > > > -----Original Message----- > > > From: isapros-bounce@xxxxxxxxxxxxx > > > > > [mailto:isapros-bounce@xxxxxxxxxxxxx] > > > On Behalf Of Thomas W Shinder > > > Sent: Wednesday, August 29, > > 2007 12:15 PM > > > To: isapros@xxxxxxxxxxxxx > > > Subject: [isapros] Re: ISA > > and SAN Certs > > > > > > BAM!!!! > > > > > > I think I get it. On the TO > > tab for the autodiscover.msfirewall.org, I > > > can still use > > owa.msfirewall.org since it resolves to the same IP > > > address as > > autodiscover.msfirewall.org on the internal network -- and > > > the path is going to > > /autodiscover, so that's cool. It's all making > > > sense on paper -- now to > > see if it works in real life :) > > > > > > BTW -- why do I need a SRV > > record for OL autodiscovery? I haven't seen > > > any documentation on that > > requirement on the Exchange side. > > > > > > Thanks! > > > Tom > > > > > > Thomas W Shinder, M.D. > > > Site: www.isaserver.org > > > Blog: > > http://blogs.isaserver.org/shinder/ > > > Book: http://tinyurl.com/3xqb7 > > > MVP -- Microsoft Firewalls (ISA) > > > > > > > > > > > > > -----Original Message----- > > > > From: > isapros-bounce@xxxxxxxxxxxxx > > > > > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison > > > > Sent: Wednesday, August > > 29, 2007 2:09 PM > > > > To: isapros@xxxxxxxxxxxxx > > > > Subject: [isapros] Re: > > ISA and SAN Certs > > > > > > > > Yes; I'd forgotten about > > the OL client's "SAN problem". > > > > It amazed me how much > > noise the Exch folks make about the same > > > > limitation for ISA.. > > ..but I digress. > > > > > > > > "Web Publishing Rule that > > is publishing the > > > > > > autodiscover.msfirewall.org/autodiscover path must be > > > > configured on the > > > > TO tab to use > > autodiscover.msfirewall.org " - how do you > > > cone to that > > > > contusion? > > > > Why do you think you need > > to use "autodiscover" in the ISA rule > > > > published hostname? Use > > whatever works for ISA and let the > > > > client be as > > > > stupid as you want. > > > > > > > > -----Original Message----- > > > > From: > isapros-bounce@xxxxxxxxxxxxx > > > > > > [mailto:isapros-bounce@xxxxxxxxxxxxx] > > > > On Behalf Of Thomas W Shinder > > > > Sent: Wednesday, August > > 29, 2007 12:05 PM > > > > To: isapros@xxxxxxxxxxxxx > > > > Subject: [isapros] Re: > > ISA and SAN Certs > > > > > > > > Hi Jim, > > > > > > > > CIL... > > > > > > > > Thomas W Shinder, M.D. > > > > Site: www.isaserver.org > > > > Blog: > > http://blogs.isaserver.org/shinder/ > > > > Book: http://tinyurl.com/3xqb7 > > > > MVP -- Microsoft Firewalls (ISA) > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: > > isapros-bounce@xxxxxxxxxxxxx > > > > > > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison > > > > > Sent: Wednesday, August > > 29, 2007 1:49 PM > > > > > To: isapros@xxxxxxxxxxxxx > > > > > Subject: [isapros] Re: > > ISA and SAN Certs > > > > > > > > > > All good points, but > > really orthogonal to the question of how ISA > > > > > handles SAN certs. > > Actually, I wrote that because some folks were > > > > > whining about how ISA > > handled SAN certs in general. In > > > > fact, I tried > > > > > not to delve into the > > variant forms of self-inflicted ISA > > > manglement > > > > > pain that were filling > > other blogs. > > > > > > > > > > Q1 - Why do you need a > > second listener? Use your DNS to point > > > > > autodiscover to the > > same Exch listener. The public name is a > > > > > rule; not > > > > > a listener arttribute. > > > > > > > > TOM: We need a second > > listener because we can't have two > > > certificates > > > > with different common > > names listening on the same listener using the > > > > same IP address. OK, in > > ISA 2006 I *can* use multiple > > > > certificates using > > > > the same listener, but > > each of the certificates must be > > > assigned to a > > > > different IP address, so > > no big deal there -- so I create two > > > > different > > > > Web Publishing Rules -- > > one for owa.msfirewall.org and a second Web > > > > Publishing Rule for > > autodiscover.msfirewall.org. So far so > > > > good and SANs > > > > aren't even an issue. > > > > > > > > > Q2 - why does the > > external OL client give a rats bahootie > > > > > what's listed > > > > > in the cert used at the > > CAS? It never sees it. > > > > > > > > TOM: That's true and I > > didn't mean to imply that it did. The > > > > concern is > > > > that common name and the > > first SAN on the Web site > > > > certificate bound to > > > > the Client Access Server > > site is owa.msfirewall.org. The > > > second SAN is > > > > autodiscover.msfirewall.org > > > > > > > > > > > > > Q3 - why is the lack of > > the autodiscover.suffix public > > > name make the > > > > > /autodiscover path > > "useless"? "Incomplete" perhaps, but > > > > > hardly useless. > > > > > > > > TOM: Because the OWA > > publishing rule is listening for > > > > owa.msfirewall.org, NOT > > autodiscover.msfirewall.org. Since > > > > there are two > > > > certificates involved > > here, one with the common name > > > > owa.msfirewall.org > > > > and a second with > > autodiscover.msfirewall.org -- we have to use two > > > > different IP addresses, > > and owa.msfirewall.org is NOT going > > > to resolve > > > > to the same IP address as > > autodiscover.msfirewall.org. Thus, > > > > adding the > > > > /autodiscover path to the > > owa.msfirewall.org Web Publishing > > > Rule won't > > > > work and is extraneous. > > The /autodiscover path only applies to the > > > > > > autodiscover.msfirewall.org Web Publishing Rule. > > > > > > > > > > > > > > IOW, create your SRV > > and A records for autodiscover.suffix, add > > > > > "autodiscover.suffix" > > to the public names (ISA 2006 only) and > > > > > make sure > > > > > the cert used in the > > ISA web listener includes > > > > > "autodiscover.suffix" in > > > > > the SAN. > > > > > > > > Again, the issue isn't > > with the Web listeners, I have no > > > problem with > > > > that. The issue is with > > the connection between the ISA > > > > Firewall and the > > > > Client Access Server. The > > Web site certificate bound to the Client > > > > Access Server has a > > common name and a first SAN name of > > > > owa.msfirewall.org and a > > second SAN name of > > > > autodiscover.msfirewall.org. > > > > > > > > Given that, the Web > > Publishing Rule that is publishing the > > > > > > autodiscover.msfirewall.org/autodiscover path must be > > > > configured on the > > > > TO tab to use > > autodiscover.msfirewall.org -- HOWEVER, and > > > this is THE > > > > QUESTION -- with the ISA > > Firewall when establishing the SSL channel > > > > between itself and the > > Client Access Server, be able to use > > > the SECOND > > > > SAN on the Client Access > > Server Web site certificate to allow the > > > > connection? > > > > > > > > Make sense? > > > > > > > > > > > > > > > > > > Jim > > > > > > > > > > -----Original Message----- > > > > > From: > > isapros-bounce@xxxxxxxxxxxxx > > > > > > > [mailto:isapros-bounce@xxxxxxxxxxxxx] > > > > > On Behalf Of Thomas W Shinder > > > > > Sent: Wednesday, August > > 29, 2007 11:33 AM > > > > > To: isapros@xxxxxxxxxxxxx > > > > > Subject: [isapros] Re: > > ISA and SAN Certs > > > > > > > > > > This is a good step in > > understanding some of the issues, > > > > but I suspect > > > > > the major problems > > people are running into relates to > > > publishing the > > > > > autodisocvery site. > > You'll notice that when you run the Exchange > > > > > Publishing Wizard in > > ISA 2006 that is includes an > > > > /autodiscover path, > > > > > which is completely > > useless, since the client is looking for > > > > > > > autodiscover.domain.com/autodiscover and not the Client > > > > Access Server > > > > > Public Name, which > > would be something like owa.domain.com. > > > > > > > > > > OK, easy problem to > > solve, right? All we need to do is > > > > create a second > > > > > Web listener on a > > second IP address and configure it to listen for > > > > > public name > > autodiscover.company.com. HOWEVER, the Client Access > > > > > Server's common/subject > > name and first SAN is owa.company.com. The > > > > > second SAN is > > autodiscover.company.com. > > > > > > > > > > So, if we put on the TO > > tab autodiscover.company.com, will > > > > ISA 2006 be > > > > > able to "consume" the > > second SAN to support to the Outlook 2007 > > > > > autodiscovery service? > > > > > > > > > > Thanks! > > > > > Tom > > > > > > > > > > Thomas W Shinder, M.D. > > > > > Site: www.isaserver.org > > > > > Blog: > > http://blogs.isaserver.org/shinder/ > > > > > Book: http://tinyurl.com/3xqb7 > > > > > MVP -- Microsoft > Firewalls (ISA) > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: > > isapros-bounce@xxxxxxxxxxxxx > > > > > > > > [mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jim Harrison > > > > > > Sent: Wednesday, > > August 29, 2007 1:10 PM > > > > > > To: isapros@xxxxxxxxxxxxx > > > > > > Subject: [isapros] > > ISA and SAN Certs > > > > > > > > > > > > > > > > > > Another isablog for > > your reading pleasure. > > > > > > > > > > > > > > > > > > > > http://blogs.technet.com/isablog/archive/2007/08/29/certificat > > > > > > es-with-mu > > > > > > > > ltiple-san-entries-may-break-isa-server-web-publishing.aspx > > > > > > > > > > > > All mail to and from > > this domain is GFI-scanned. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > All mail to and from > > this domain is GFI-scanned. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > All mail to and from this > > domain is GFI-scanned. > > > > > > > > > > > > > > > > > > > > > > > > > All mail to and from this > > domain is GFI-scanned. > > > > > > > > > > > > > > > > All mail to and from this domain is GFI-scanned. > > > > > > All mail to and from this domain is GFI-scanned. > > > > > > > > > > > > All mail to and from this domain is GFI-scanned. > > > > > > > > > > > > All mail to and from this domain is GFI-scanned. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >