Haiku #24

What gives you the right?

Oh, so that gives you the right.

Well, carry on then.

If you've ever seen an old World War II war movie then you know that any time an American sentry encountered an unknown person he would never demand to see that person's papers or his dog tags; after all, anyone could forge papers or steal a set of dog tags. Instead, the sentry would pose a question like this: "Who won the 1944 World Series?" If the unknown person knew the answer (the St. Louis Cardinals) then the sentry would assume that he was dealing with an American and would let the guy go about his business. But if the unknown person didn't know the answer, well, then that meant he obviously wasn't an American, and was just as obviously a spy or a saboteur. Needless to say, that meant the unknown person would not be allowed to go about his business.

To say the least.

Note. Um, you knew that the Cardinals won the 1944 World Series, didn't you? Just checking ….

Now, if anyone had asked us, we would have proposed a similar mechanism for determining which administrative tasks a user can perform in Microsoft Lync Server 2010. For example, you say you need to modify the global address book settings? That's fine; you can do that. Just tell us who holds the National League record for most doubles in a single season.

Note. In case you're wondering, or in case you really need to change those global address book settings, the correct answer is Joe "Ducky" Medwick. Who, coincidentally enough, played for the St. Louis Cardinals.

And that's a good point: the other side probably would have won the war if they'd just brushed up on their St. Louis Cardinals history.

For some reason, however, no one ever asked us how we would implement the delegation of control in Lync Server 2010. Instead, the product team came up with a different method for delegating control in Lync Server: RBAC (role-based access control).

We're not going to discuss RBAC in any detail today; for an introduction to RBAC in Lync Server 2010, take a look at the article A Brief Introduction to Role-Based Access Control – Part 1. And before you ask, no, there isn't a Part 2 to this series, at least not yet: Part 2 got put on hold after the product made a ton of changes to RBAC right before the second article was going to be published. Instead of a Part 2, we're working on a comprehensive overview of all things related to RBAC, although it will be a little while before that's ready to go.

So what are we going to talk about today? Today we're going to talk about the Get-CsAdminRoleAssignment cmdlet. How did our World War II sentries know if someone was authorized to be in a given area? They simply asked them who won the World Series in 1944. (Or at least they did in 1945. We're not sure what they did in 1942, two years before the 1944 World Series was even played.) And how can you, a Lync Server administrator, know whether or not someone is authorized to perform a given management task? You simply run the Get-CsAdminRoleAssignment cmdlet and see what RBAC roles have been assigned to that person.

In other words, Get-CsAdminRoleAssignment does only one thing, but it does it quite well: it tells you which RBAC roles have been assigned to a user. For example, suppose you need to know which RBAC roles (if any) have been assigned to Ken Myer. All you have to do is run a command similar to this one:

Get-CsAdminRoleAssignment -Identity "kenmyer"

As you can see, that's a pretty simple command; the only tricky part lies in the way you specify the user's Identity. Typically, Lync Server PowerShell lets you specify a user ID in all sorts of ways: Active Directory display name; SIP address; user principal name; Active Directory distinguished name; etc. etc. With Get-CsAdminRoleAssignment, however, you must use the user's SamAccountName.

Period.

Ah, good point: what if you don't actually know the user's SamAccountName? That's a problem; not only does it mean you can't run the Get-CsAdminRoleAssignment cmdlet, but it could also mean that you're a spy or a saboteur. Fortunately, though, you can retrieve the SamAccountName for a user by running a command similar to this one:

Get-CsAdUser "Ken Myer" | Select-Object SamAccountName

Alternatively, you can use a command like this one to both retrieve the SamAccountName and to display the list of RBAC roles assigned to the User:

Get-CsAdUser "Ken Myer" | ForEach-Object {Get-CsAdminRoleAssignment –Identity $_.SamAccountName}

What we're doing in that command is first retrieving user account information for the user with the display name Ken Myer; we then pipe that collection of user data to the ForEach-Object cmdlet. In turn, ForEach-Object calls the Get-CsAdminRoleAssignment cmdlet for each account in the collection, using $_.SamAccountName as the user Identity. ($_.SamAccountName simply means this: use the SamAccountName of the current user in the collection.) It's a little goofy, but it works.

So why didn't we just use a command like this one, a command that pipes Ken Myer's user account information directly to Get-CsAdminRoleAssignment in order to retrieve the RBAC role information:

Get-CsAdUser "Ken Myer" | Get-CsAdminRoleAssignment

Unfortunately, that command won't work. Why not? Well, Get-CsAdUser uses the Active Directory distinguished name as the user Identity; that's a value that looks similar to this:

CN=Ken Myer,CN=Users,DC=litwareinc,DC=com

That's fine, except for one thing: Get-CsAdminRoleAssignment can't use an Identity like that. As we noted earlier, Get-CsAdminRoleAssignment has to use the SamAccountName as the Identity. Consequently, we had to find a way to hand Ken Myer's SamAccountName over to Get-CsAdminRoleAssignment; using the ForEach-Object cmdlet was the method we came up with. Are there other ways of doing this? Probably. If you know of any, we'd love to hear from you.

In the meantime, that's all we have time for today. We'll see you tomorrow, provided that you can correctly answer this question: The Boston Americans won the 1903 World Series, but who won the 1904 World Series? Needless to say, your future as a Lync Server administrator depends on your answer.

Well, it would if we'd been in charge of Lync Server development. Maybe for the next release ….