Yes I have it published on our side using 9.210. 9.210 gives you the NTLM login which is better for Office applications.
It is important to ensure you have set up alternate access mappings in SharePoint to ensure the relevant site is allowed in IIS.
At the UTM end it is quite straightforward, a case of setting up the web server and map it to the real web server at the root. I started out with the UTM doing the authentication when NTLM wasn't supported, but now I just pass it through to the SharePoint web farm to do the authentication.
Is it not insecure passing it straight to the server?
This is the workaround posted by another forum member:
1. Bounded additional IP address to existing LAN connection on Windows server hosting Sharepoint services.
2. Sharepoint Central Administration -> Application Management -> Create or Extend Web Application -> Extend an existing Web application: - Web Application: Sharepoint-80 - Create a new IIS web site: Sharepoint-UTM - Port: random - Host Header: none - Authentication provider: NTLM - Allow Anonymous: No - Use Secure Sockets Layer (SSL): No - Zone: Custom
3. Sharepoint Central Administration -> Operations > Alternate Access Mappings: - Changed "URL protocol, host and port" to public DNS FQDN (http://portal.company.com) - Changed Zone to Default
4. Edited IIS Sharepoint-UTM web site properties: - IP address: additional IP address defined earlier - TCP port: 80 - Directory security -> Authentication methods: * Only Basic authentication selected * Default domain/Realm: internal AD DNS name
5. UTM Webserver Protection: - Created new Real Webserver definition with internal additional Sharepoint server IP address and port 80 - Created new Virtual Webserver definition: * Interface: External UTM address * Type: Encrypted (HTTPS) & Redirect * Port: 443 * Certificate: SSL certificate from public CA, previously imported on UTM * Domains: public FQDN from SSL certificate * Real Webservers: Sharepoint * Firewall profile: No profile (this should be changed after succesfull testing to more restrictive one) * Pass Host Header selected
6. UTM Reverse Authentication: - Created new Form Template named "Sharepoint" and uploaded custom html and css files (more info on this in another forum thread - Reverse Auth - Custom Form Template) - Created new Authentication Profile: * Virtual Webserver _ Name: Sharepoint Reverse _Mode: Form _Form Template: Sharepoint _Users/Groups: Active Directory Users * Real Webserver _ Mode: Basic _User name affix: none * User session (as desired) _ Session Timeout: 60 minutes _Session Lifetime: Deselected - Edited Site Path Routhing properties for Sharepoint virtual webserver and changed Reverse Authentication parameter to "Sharepoint Reverse" profile.
Yes I am using the passthrough NTLM feature and not authentication on the UTM.
If you use the UTM authentication feature in the way the poster describes then getting Office apps connected to SharePoint isn't going to work.
If you set up authentication on the UTM and use basic authentication instead of the HTML based authentication then Office apps will work, but prompt for credentials when they access the document. The NTLM passthrough gets rid of this popup if the user logs in using cached credentials into their domain account.
The downside by passing the authentication to SharePoint directly is that the request goes straight through to the backend server whereas if the UTM does authentication then it can filter connections from invalid users. At some point I hope the authentication support on the UTM can work with NTLM rather than just basic authentication, but at least we have NTLM pass-through now!
I have a similar setup except I use SSL on SharePoint as well as I don't like going from SSL to non-SSL at the backend.
Hi Andrew...(I am the original poster btw...[[:)]])
This guide was written for WSS 3.0 services behind UTM, while testing TMG to UTM migration for a client in my lab environment.
This client currently use HTTP in LAN, but HTTPS to HTTP redirection for outside access with custom TMG login form. This is perfect solution for them, and should be migrated to UTM. As far as I know NTLM authentication cannot be passed with UTM reverse form authentication method ?
I am not very familiar with SharePoint, so any suggestions for better solution than posted above are welcome. The project is still in procurement phase, so I have a lot of time to change my design...[[:)]]
Yes we replaced a TMG installation with a UTM for both Exchange and SharePoint. If the UTM doesn't do authentication (i.e, no auth profile), then everything is dependant on the configuration of IIS and SharePoint. For example, the web application you have deployed the application in and its authentication settings.
I configured the external access in a different web application which used HTTPS and a different FQDN. I enabled NTLM on that application. It is better to create this application because the internal and external hostnames are different for our SharePoint instance.
In our environment the user gets prompted for creds if they aren't logged in with a domain account, but if they are logged on with a domain account it passes the authentication through. You don't need to do anything to get NTLM passthrough to work, it just works as long as there is no authentication profile defined.
What is the setting of the authentication profile on that virtual web server? The trick I found when using authentication on the UTM was putting in the correct username so it matched the AD account (the UTM needs to be able to get data from the AD, not joined to the domain as such but needs to be able to authenticate against AD), and SharePoint needs the basic authentication allowed in IIS for the relevant application.
