1 2 3 4 5?
That's not an acceptable
Pin. Please try again.
We don't wish to alarm anyone, but we felt a duty to call your attention to this. As you may have heard, the Mayan calendar runs out on December 21, 2012. And the minute that calendar runs out, the world is destined to come to an end!
That's what we said: Eep.
Of course, right now you're probably thinking, "Gosh, how can the authors of the Lync Server PowerShell blog save the Earth?" Well, to be perfectly honest, we can't: we're all doomed. What we can do, however, is help to make everyone's last few months on Earth as pleasant as possible. Suppose we had only a year or so left to live, we thought to ourselves. (Which, if the prophecy is correct, is all we do have left.) How would we like to spend that time? The answer, of course, was easy: we wanted to be with our families, relaxing on a tropical beach, and using the CsPinPolicy cmdlets (Get-CsPinPolicy, Grant-CsPinPolicy, New-CsPinPolicy, Remove-CsPinPolicy, and Set-CsPinPolicy) to manage dial-in PIN settings for Lync Server users. Needless to say, we figured you'd want to do the same.
Thus the reason for today's haiku. If you aren't sure what dial-in PIN policies are, or why you'd want to manage them, let's take one of our few remaining moments on Earth to explain. As you probably know, Lync Server provides a way for users to connect to the system and/or dial into audio conferences using any old telephone. As you also know, when you connect to Lync Server you typically need to provide a user name and password. Is that a problem? Well, not if you have a name like 546 82341. But suppose you have a name like Ken Myer (that is, a name that contains letters as opposed to numbers). In that case, that is a problem: entering alphabetic characters using a standard telephone keypad isn't all that easy. (You should see the author of today's haiku trying to send text messages to his son. It's not a pretty sight.) Therefore, Lync Server gives dial-in users the option of authenticating by using a PIN number; instead of entering a user name and password, dial-in users can type in a PIN number like this: 121989. That's a tad bit easier, to say the least.
So what do you need PIN policies for? Well, PIN policies enable you to place some restrictions on the PIN numbers that users can and cannot use. You know how you use password policies to prevent all your users from using a password like this one: password. Well, that's one reason to use PIN policies: it prevents all your users from using 12345 as their PIN number.
So what kind of restrictions can you impose using PIN policies? Well, for one thing, you can specify the minimum number of digits that must be used in a PIN. By default, the global PIN policy requires you to have at least 5 digits in a PIN; a user who tries to use the PIN 9827 will have that PIN rejected. (Why? Because it only contains 4 digits.) The minimum number of digits can be set to any integer value between 5 and 24, inclusive. For example:
Set-CsPinPolicy –Identity global –MinPasswordLength 8
And then there's the AllowCommonPatterns parameter. When set to False, this setting prevents users from creating PINs that consist solely of repeating digits or consecutive digits. For example, a PIN like this will be rejected:
So will a PIN like this one:
However, you can use consecutive digits as long as you break the pattern in some way. In other words, this PIN will be allowed:
Why? Because while there are consecutive digits, the entire PIN does not consist of consecutive digits. The same thing is true for repeating digits. This PIN will be rejected:
This one will not:
It's not super-duper password protection by any means, but it does help.
Oh, and here's how you allow/disallow common patterns:
Set-CsPinPolicy –Identity global –AllowCommonPatterns $False
You can also set an expiration date on PINs, meaning that users will have to periodically get a new PIN number (just like they periodically have to get a new password). To do that, you need to do two things:
· Set the PinLifetime parameter to the number of days a PIN is valid before it expires. For example, setting PinLifetime to 90 means that the PIN will expire 90 days after it's issued.
· Set the PinHistoryCount parameter to a value greater than 0. PinHistoryCount specifies how often a user can use the same PIN. For example, suppose PinHistoryCount is set to 2 and the user has the PIN 071267. When the user needs to refresh his or her PIN, they cannot reuse PIN 071267; they have to pick a different PIN. What happens the next time they need to refresh their PIN? Because this is the second time they've had to pick a new PIN they, again, cannot use 071267. However, the third time they have to select a new PIN they can reuse 071267. That's because the PinHistoryCount is set to 2. If that value was set to 10 they would have to wait until the 11th try before they could reuse a PIN.
If you set a value for the PinLifetime parameter then you must set PinHistoryCount to a value greater than 0.
Here's how all that might look:
Set-CsPinPolicy –Identity global –PinLifetime 30 –PinHistoryCount 5
In case you're wondering, PIN policies can be assigned to the global, site, or the per-user scope. Use New-CsPinPolicy to create new policies and use Set-CsPinPolicy to modify existing policies. You can probably figure out for yourself what Get-CsPinPolicy, Grant-CsPinPolicy, and Remove-CsPinPolicy do.
That's all we have for today. Again, we didn't mean to alarm anyone by revealing that the world is going to come to an end on December 21, 2012; we just felt that most people would prefer to hear that kind of news from the authors of the Lync PowerShell blog. And for those of you who remain skeptical, consider this: today's haiku is haiku number 72. What do you get if add the digits in 72 together? You get this:
7 + 2 = 9
What do you get if you add the digits in 12/21/12 together? See for yourself:
1 + 2 + 2 +1 + 1 + 2 = 9
Now, guess how many letters there are in PinPolicy? Coincidence? If it makes you feel better then, sure, it's all just a coincidence ….
But if you have a dentist appointment for December 22, 2012, well, you might consider rescheduling, if you know what we mean.