If you can authenticate from a public connection, you’re most of the way there. It will accept your domain credentials and give you a basic landing page stating “You have created a service”. To validate this URI, initiate a browser connection to and if it’s listening properly, you’ll get a login dialog. This authentication is critical to all reverse proxy web services and will cause very odd behavior in a failure scenario, I’ll give examples later. The secondary authentication creates a client session token from a front end server via the web service's Certificate Provisioning Services published URI ( a great write up on this is found here). 1 houses a potential hidden evil A SECONDARY AUTHENTICATION! Breath deep! It’s ok. The previously mentioned secondary connection our client makes to the Lync/Skype web services in Fig. Places of Potential Failure (read: where everything blows up) Microsoft’s cert creation wizard will potentially add more names than you need, so just pay attention. If you want to do this on two separate certificates (one for web services and one for edge services) that’s fine, if you want to create one mega SAN cert, go for it. Microsoft makes this fairly easy so don’t try to deviate TOO far from recommended configurations. We also install this certificate chain on the external web services defined within the Lync/Skype installation wizard, allowing us to separate certs for internal and external features. 1 and instead I’ll bridge SSL at the internal front end pool virtual listening on 4443 again for simplicity and testing. Seeing that I use a fastL4 for the reverse proxy functionality, there’s no SSL termination/bridge required at the external LTM in Fig. I purchased my Entrust certificate and it included two bonuses, the CA root and intermediary chain certs they're super important later. You’ll still add all other CNAME’s to the SAN certificate and Lync/Skype’s cert builder will configure this for your public and private domains. We now have published public DNS records, all used by the reverse proxy, only one name requires a host record binding, the FQDN defined in topology builder for the external web services (in our example ). From here let’s build certs to get this listening on 443. Remember, we’re starting simple to make sure we get it working first. Microsoft’s certification process ensures the device(s) responsible for reverse proxy functionality allow their services to work, any extra features added are secondary and up to the admin for ownership and support. You could add authentication mechanisms and security features with ASM/APM, but when we certified BIG-IP for Lync Reverse Proxy, we achieved validation using a FastL4 virtual translating 443 to 4443 only. The client also initiates a secondary connection to the web services namespace (lyncwebservices.fqdn listening on 443/80 in Fig. Primary client login is achieved via SIP registration through edge services (access:443). 1 shows the mobile client initiating two separate connection points into our Lync/Skype environment. When deploying reverse proxy services at F5 (and certifying our functionality for Microsoft), we simply CNAME’d the meet, dialin, and lyncautodiscover namespaces to the FQDN of the web service IP. (this name is up to you and added to topology builder during deployment).Services managed through reverse proxy are required for mobile, autodiscover, and extended collaboration services presented via the following public DNS entries: External connections are port redirected to internal front end pools, listening on 44 respectivly (if you don't redirect 80 to 443 as we do). Deploying reverse proxy starting with simple configurations and working up to your more complicated requirements will significantly reduce headaches down the road.Īt it’s core, the reverse proxy functionality for Lync/Skype is a simple public endpoint listening on port 80 and 443. Looking at support call metrics, we bundled a rather high percent of support cases into two specific issues certificate deployment problems and misconfigurations with port redirection. Regardless if you deploy Lync/Skype via iApps or manually define your BIG-IP elements, there’s rumbling suspicion of witchcraft around how this works. At F5’s Agility conference, I spoke briefly about troubleshooting Lync/Skype for Business Reverse Proxy at the request of our support people.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |