Share via


Haiku #148

It's a dirty job,

And we don't have to do it.

Kerberos passwords.

 

Today is going to be a great day. How do we know that? Well, for one thing, it's currently 55 degrees and drizzling here in Redmond; how could you not have a great day after you get off to a start like that? On top of that, when the author of today's haiku sat down at his desk this morning, he realized that his sweatshirt (yes, you pretty much have to wear sweatshirts in July around these parts) was completely filthy: it looked like he'd spent the morning replacing the engine in a diesel train. Did he spend the morning replacing the engine in a diesel train? To the best of his knowledge, no, he did not. But, then again, he is a pretty resourceful fellow, so who knows?

 

Note. Did he at least change his sweatshirt? No, not yet anyway. Why not? Well, for one thing, we might remind everyone that it's currently 55 degrees and drizzling here in Redmond; he doesn't want to get hypothermia or something. For another, he doesn't actually have anything to change into: despite the fact that he apparently spent the morning replacing the engine in a diesel train, he didn't bring a change of clothes with him. Hey, who knew diesel trains would be so messy?

 

But the main reason we know that today is going to be a great day is this one: today's haiku is all about the Set-CsKerberosAccountPassword cmdlet.

 

That's what we said: hurray!

 

So what's so great about the Set-CsKerberosAccountPassword cmdlet? Well, as you no doubt know by now (especially those of you who wouldn't dream of missing even one of the daily Lync Server PowerShell haikus), one of the many innovations introduced in Microsoft Lync Server 2010 is the notion of Kerberos accounts. What's a Kerberos account? Well, in Office Communications Server 2007 R2, Web services ran under a plain old user account. Was that a problem? Well, sometimes. For one thing, in most organizations user account passwords are designed to expire from time-to-time; if your Web service password expired, that could potentially wreak havoc throughout your entire system. (As you also know, Web services are a key component in the Lync Server infrastructure.)

 

Furthermore, changing passwords on all your Web services could be a major hassle, to say the least. If you only have one Web server, well, no big deal. But what if you have 15 or 20 Web servers and you need to change the service account password on each one of those servers? Needless to say, it would be faster, easier, and a lot more fun to replace an engine in a diesel train than to have to change all those passwords.

 

Note. And if anyone would know that it would definitely be the greasy, grimy author of today's haiku.

 

That's great, but what is a Kerberos account? Well, a Kerberos account is a computer account (that doesn't represent a real computer) that can be used as the authentication principal for Lync Server's Web services. One of the advantages of using this approach is that a single account can then be used as the authentication principal for multiple Web servers. You say you have 15 or 20 Web servers? That's fine: if you want to, you can configure all 15 or 20 of those Web servers to use the same Kerberos account. In turn, that also means that, if you ever do need to change the password for this account, you can run a single command that will update the password for every single one of your Web servers.

 

Hey, would we kid you about a thing like that? Here's a sample command that assigns a new password to the Kerberos account litwareinc\RedmondWebServices; that results in a password update to every single Web server that uses that account:

 

Set-CsKerberosAccountPassword -UserAccount "litwareinc\RedmondWebServices"

 

You know, you're right: that is pretty easy, isn't it? Note that all you have to do is call the cmdlet and specify the name of the account that is getting the new password. You don't even have to come up with a new password for the account; Lync Server will take care of that for you.

 

And you thought we were joking when we said this was going to be a great day.

 

What our sample command does is update the password for all the Web servers currently up and running, and currently using the Kerberos account litwareinc\RedmondWebServices. But suppose you set up a new Web server, and configure that server to use the RedmondWebServices account? How are you supposed to ensure that the correct password is used on the new server?

 

Why, like this, of course:

 

Set-CsKerberosAccountPassword -FromComputer "atl-cs-001.litwareinc.com" -ToComputer "dublin-cs-001.litwareinc.com"

 

What did we do here? We simply copied the password from the Webserver atl-cs-001.litwareinc.com to our new Web server, dublin-cs-001.litwareinc.com. Again, you don't need to create a new password and you don't even need to know the existing password. Set-CsKerberosAccountPassword is happy to do all that for you.

 

And that's pretty much all there is to Set-CsKerberosAccountPassword. Which is good, too, because we're just about out of time, and we have other things that we have to get to this morning. Those diesel train engines don't replace themselves, you know.

 

See you Monday.

 

Note. What's that? Is it possible that the author of today's haiku got that dirty by working really, really hard on something other than replacing an engine in a diesel train? Hey, that's pretty funny: the author of today's haiku working really, really hard on something. You don't mind if we use that in a future article, do you?