Haiku #119

[NextHop_Team]

First published on TECHNET on May 26, 2011

Don't get scrammed and don't

Worry about your passwords.

Kerberos accounts.

This morning the author of today's haiku noticed an email in his Junk Mail folder that had the following subject line:

DON'T GET SCRAMMED!!!

Definitely not wanting to get scrammed, the author of today's haiku proceeded to read the email, which including the following note:

"Today many people on the Internet are victims of fruads and scrams. For example, you might be told to click a link and go to web site where you enter personal information; scrammers can then use this personal information for indentity theft. DON'T GET SCRAMMED!!!"

Gadzooks! thought the author of today's haiku. It's bad enough to have people try to steal your identity but now they're apparently trying to take your indentity as well. Is there no decency left in this world?

So how can you avoid getting scrammed? The email suggested that you go to their Web site and enter your personal information, including your credit card numbers. After that, they will "monitor the entire Internet and notify you if anyone tries to use this information or tries to buy something with your credit card." And how much will all this cost? Nothing ! The service is entirely free.

And yes, we know what you're thinking: how could a service that monitors the entire Internet be free? Well, as it turns out, this service is sponsored by the US government. See? Nothing to worry about.

Note . We know what you're thinking now, too. On the other hand, based on their inability to reach any other sort of consensus, it's really not all that far-fetched to imagine politicians agreeing to resort to fruads and scrams as a way to solve the current budget crisis.

At any rate, something to think about, eh? Trust us: you do not want to get scrammed.

Which is all the more reason to continue visiting the Lync Server PowerShell blog which, after nearly a year in existence, has yet to scram even a single person! Instead of scramming people, we like to tell you about useful things, like the CsKerberosAccountAssignment cmdlets ( Get-CsKerberosAccountAssignment , New-CsKerberosAccountAssignment , Remove-CsKerberosAccountAssignment , and Set-CsKerberosAccountAssignment ). And if you'll just send us your credit card numbers, we'll be happy to tell you about this cmdlet.

Nah, just kidding. Although – nah, never mind.

As the name implies, the CsKerberosAcocuntAssignment cmdlets are used to assign Kerberos accounts. What are Kerberos accounts? As you know, in Microsoft Office Communications Server 2007 and Microsoft Office Communications Server 2007 R2 your Web services all ran under a standard user account. Was that a problem? Well, it could be: if the password for that account expired you could lose those Web Services, an issue that was often difficult to diagnose. To help avoid this problem, Lync Server enables you to create a computer account (for a computer that doesn’t actually exist) that can serve as the authentication principal for all the computers in a site (or at least all the computers that are running IIS and a Lync Server Web service). Because these accounts use the Kerberos authentication protocol we cleverly refer to them as Kerberos accounts, and have dubbed the new authentication process as "Kerberos web authentication." The punch line? Kerberos web authentication lets you manage all your Lync Server Web servers by using a single account. The password for that one account could still expire, but there's only one account (and one password) you have to worry about, and we even provide a very simple way for you to change that password ( Set-CsKerberosAccountPassword ).

So how do you implement Kerberos web authentication? Well, the first step is to create a Kerberos account; that's an activity we discussed in haiku 85 . (Thank you; it's our favorite haiku, too.) After you have an account, you can then assign it to one or more of your Lync Server sites (one account per site, although the same account can be used in multiple sites). For example:

New-CsKerberosAccountAssignment -UserAccount "litwareinckerberostest" -Identity "site:Redmond"

Enable-CsTopology

As you can see, all we've done here is taken an existing account – litwareinckerberostest – and assigned it to the Redmond site. (And yes, the parameter is UserAccount, even though a Kerberos account is actually a computer account. That's just one of those quirky things that make Lync Server PowerShell so lovable.) And then after we make the assignment we call the Enable-CsTopology cmdlet in order to create the required service principal name and effectively seal the deal.

Not bad, huh? Now, suppose you want to assign the same Kerberos account to all your sites. Can you do that? You bet, although it takes a tiny bit more work than you might first expect. That's because the New-CsKerberosAccountAssignment cmdlet won't take pipelined input. That means that a command like this one will fail:

Get-CsSite | New-CsKerberosAccountAssignment -UserAccount "litwareinckerberostest"

But that's fine. Instead of retrieving all our sites and piping them directly to New-CsKerberosAccountAssignment we can pipe that data to the ForEach-Object cmdlet and let ForEach-Object take care of things for us:

Get-CsSite | ForEach-Object {New-CsKerberosAccountAssignment -UserAccount "litwareinckerberostest" –Identity $_.Identity}

Note . Trust us, that is not a scram. It really works.

Needless to say, you can then use Get-CsKerberosAccountAssignment to retrieve information about the assignments already made in your organization, and use Set-CsKerberosAccountAssignment to modify any of those existing assignments (which basically means assigning a different Kerberos account to a site). You can also use the Remove-CsKerberosAccountAssignment cmdlet to delete an assignment:

Remove-CsKerberosAccountAssignment -Identity "site:Redmond"

Enable-CsTopology

Or, to delete all the assignments:

Get-CsKerberosAccountAssignment | Remove-CsKerberosAccountAssignment

Enable-CsTopology

Note that deleting an assignment doesn't delete the corresponding computer account from Active Directory; all it does is configure things so that your Lync Server Web servers in the specified site no longer use Kerberos web authentication. Instead, they'll use whatever authentication method/user account was configured before you set up Kerberos web authentication.

See? That wasn't so bad, was it? And now if you'll excuse us, we need to run to the bank. After reading about fruads and scrams this morning we came up with a great idea. Banks get robbed all the time, typically by people who walk into a bank and demand that all the money be taken out of the vault and put into a brown paper bag, right? Well, we thought we'd go into the bank and tell them, "Look, we know you get robbed all the time by people who demand that all the money be taken out of the vault and put into a brown paper bag. In order to protect you and your money, why don't you take all the money out of the vault and put it into our brown paper bag. And then, if anyone tries to steal that money, we'll notify you immediately."

Hey, it sounds good to us . We'll let you know how it goes.