Haiku #178
Kerberos? OK,
Then you can come in. Proxy
Configuration.
TGIF: Thank God it's Friday! Needless to say, after a difficult week in which he had to work two days in a row, the author of today's haiku is excited to see the weekend coming. And not a moment too soon.
You know, we wondered the same thing: is working two days in a row the most days in a row than anyone has ever had to work? Surprisingly, the answer is this: no, it's not. The author of today's haiku didn't have much luck determining the world's record for most consecutive days at work, but he did find evidence of tons of people who've worked for more than 100 days in a row. As near as he can tell, there really aren't a lot of laws governing the number of days you have to work in a row. If you work more than 40 hours in a week your employer has to pay you for those extra hours, but if you have to work 2 days in a row, or even more than that, well ….
Note. In trying to determine the world's record for most consecutive days at work, the author of today's haiku stumbled upon the following question in a labor law newsgroup:
"Can my employer make me work more than 7 days in a week?"
Unfortunately, no one answered that question. We'll continue to look into it, and let you know what we find out.
At any rate, although we're obviously a bit tired after this long week, we still have a job to do: we have to tell everyone about the CsProxyConfiguration cmdlets (Get-CsProxyConfiguration, New-CsProxyConfiguration, Remove-CsProxyConfiguration, and Set-CsProxyConfiguration). Now, to be perfectly honest, we're not sure that the name CsProxyConfiguration is the best name that could have been given to these cmdlets. (On the other hand, we're even less sure what that best name would be.) Why do we say that? Well, to begin with, the CsProxyConfiguration cmdlets are used to help govern the client-server relationships for Edge servers and Front End servers. That's good; that's something you definitely do want to manage.
However, traditionally the term proxy refers to a proxy server, a computer that acts as an intermediary between a client and a server: the client sends a request to the proxy server, the proxy server forwards the request to the server, the server sends an answer back to the proxy server, and then the proxy server shuffles the answer on to the client. (Yes, just like the old gag, "Well, you tell her that she can just ….") That's actually a pretty good (albeit highly-simplistic) definition of what an Edge server does. But is it an equally good definition of what a Front End server does? Well ….
But all that's beside the point. (Or at least we assume it is, seeing as how we can't remember what the point was in the first place.) The important thing to note is that client-server relationships can be managed using the CsProxyConfiguration cmdlets. And that includes the one thing that everyone wants to manage: the authentication mechanisms that client applications can use to log on to Lync Server.
Note. How do we know that's the one thing that everyone wants to manage? Well, we don't really know that for sure. What we do know is that the CsProxyConfiguration cmdlets can manage all sorts of things; for example, you can decide whether you want to compress messages between your server and your client endpoints, or your server and other Lync Server servers. However, these settings are available only if you use one of the CsProxyConfiguration cmdlets; the Lync Server Control Panel exposes only the authentication settings. (Click the Security tab and then click Registrar.) That typically means that the product team decided that the authentication settings are the settings of most interest to most people.
And who are we to argue with the product team, right? With that in mind, let's review the three authentication settings available to you:
· UseCertificateForClientToProxyAuth. When set to True (the default value), client endpoints can use certificates for authentication.
· UseKerberosForClientToProxyAuth. When set to True (the default value), client endpoints can use the Kerberos protocol for authentication. Although Kerberos is a more secure protocol than NTLM, it cannot be used if the client belongs to a different domain than the server.
· UseNtlmForClientToProxyAuth. When set to True (the default value), client endpoints can use the NTLM protocol for authentication. Although NTLM is a less secure protocol than Kerberos, NTLM can be used if the client belongs to a different domain than the server. That is not true for Kerberos authentication.
As you can see, by default client applications can log on using certificates, Kerberos authentication, or NTLM authentication. But suppose you don't want to allow certificate-based logins; what can you do about that? Well, one thing you can do is use the Set-CsProxyConfiguration cmdlet to disable certificate authentication:
Set-CsProxyConfiguration –Identity global –UseCertificateForClientToProxyAuth $False
If you only want to allow Kerberos authentication, then turn off both NTLM and certificate authentication:
Set-CsProxyConfiguration –Identity global –UseCertificateForClientToProxyAuth $False –UseNtlmForClientToProxyAuth $False
That's all you have to do.
Speaking of NTLM authentication, here's an interesting little parameter that no one knows about: DisableNTLMFor2010AndLaterClients. What's so interesting about that little parameter? Well, suppose you have some older client applications that can't use Kerberos authentication; that means you can't turn off Kerberos authentication altogether. However, what you can do is set DisableNTLMFor2010AndLaterClients to True. If you do, Lync Server will allow older clients to use NTLM authentication; however, anyone running Microsoft Lync 2010 (or a later version) will not be allowed to use NTLM authentication. Instead, all those shiny new client applications will have to use Kerberos.
Oh, yeah, we almost forgot: here's what the code for that looks like:
Set-CsProxyConfiguration –Identity global –DisableNTLMFor2010AndLaterClients $True
As you probably already guessed, the Set-CsProxyConfiguration cmdlets are used to modify existing proxy configuration settings. What if you wanted to create new proxy configuration settings? No problem: just use the New-CsProxyConfiguration cmdlet. New settings can be configured at the site scope or at the service scope (for either the Edge service and/or the Registrar service). For example, suppose you don't want to allow certificate authentication on one of your Edge servers. How do you prevent that? Like this:
New-CsProxyConfiguration –Identity "service:EdgeServer:atl-edge-001.litwareinc.com" –UseCertificateForClientToProxyAuth $False
Just specify the Identity of the Edge server in question, and away you go.
Note. You say you don't know your Edge server identities? Then just run this command:
Get-CsService –EdgeServer
And here's an exciting variation on the preceding command: it creates new proxy settings for all your Edge servers:
Get-CsService –EdgeServer | ForEach-Object {New-CsProxyConfiguration –Identity $_.Identity –UseCertificateForClientToProxyAuth $False}
The fun just never stops, does it?
And what if you later decide to delete some (or even all) of these handmade proxy configuration settings? As you might expect, that's the job of the Remove-CsProxyConfiguration cmdlet. For example:
Remove-CsProxyConfiguration –Identity "service:EdgeServer:atl-edge-001.litwareinc.com"
Or how about this example, which removes all the settings configured for individual Edge servers:
Get-CsProxyConfiguration –Filter "service:EdgeServer:*" | Remove-CsProxyConfiguration
Pretty cool, huh? In this case, we used the Get-CsProxyConfiguration cmdlet and the Filter parameter to return all the proxy configuration settings that have an Identity that begins with the string value service:EdgeServer: ; by definition, those are going to be settings configured for an individual Edge server. And then, of course, we pipe that collection to the Remove-CsProxyConfiguration cmdlet, which proceeds to get rid of all the settings in that collection.
Which reminds us: we should probably mention that Get-CsProxyConfiguration lets you return information about your existing proxy configuration settings. For example, suppose someone asks if any of your proxy configuration settings prohibit certificate authentication. How can you determine the answer to that question? Why, by running this command, of course:
Get-CsProxyConfiguration | Where-Object {$_.UseCertificateForClientToProxyAuth -eq $False}
And so on and so on.
That's about all we have for today; after all, the weekend is practically here. We'll see you again on Monday, the first day of our heroic effort to try to work five days in a row. Will we succeed? Only time will tell.
But don't count on it.