I feel a previously scheduled engagement coming on…    -DH

The status quo blows… -KS

Is the user in the group?

Initial disclaimer:  I am not a developer.  I don’t even play one on TV.

However, now that that’s out of the way, since I am “the AD guy” who’s usually around in MS IT, and am more often than not willing to answer questions (whether I know the answer or not), I tend to get a lot of questions around programs interacting with AD.  One question, which I’ve been asked at least 3 times (in various forms) in the past few months, goes something like this:

“When a user comes to my application, query the member attribute of the security group that we want, and then loop through it to see if the user is a member.  This worked great until we expanded our pilot, and there are now 7,000 members of the group.  Is there a more performant way of doing this?  We have tried using isMemberOf, but that doesn’t work so well either”

Now, I figure there are probably better ways built into the OS to do this to begin with, but then again, maybe not…  At least not in the “edge case” territory, which is where I often seem to live.  The reply that I’ve started to give, goes something like this:

If all you really care about, is whether the user is a member of a specific group, then that’s what you should ask AD. 

 

More specifically, you should change your code so that it gets the distinguished name of the user, and then query AD for “all security groups, with the name <your group here>, that contain user <userDN>.  To see if BPuhl is a member of the FooBar security group, it would look something like this:

 

First, get the DN for BPuhl:  cn=bpuhl,ou=users,dc=ms,dc=com

 

Second, check to see if there is a group that he’s a member of:

       (&(cn=foobar)(member=cn=bpuhl,ou=users,dc=ms,dc=com))

                 or

       (&(samAccountName=foobar)(member=cn=bpuhl,ou=users,dc=ms,dc=com))

 

Depending on how they “know” the name of their group, either way the performance is the same

 

With this query though, If you get an object back from AD, then the object will be your security group, and you will implicitly know that the user was a member.  If the user isn’t a member, then AD will return back nothing, because there “are no security groups with a name of foobar that contain user bpuhl”

I’m sure there are better ways of doing this, but I get the impression that they become implementation specific, etc… and the folks who are usually asking the question are IT pro’s instead of developers, and tend to be fairly light, even on .NET stuff.

If anyone else has a better answer to this question though, I’d love to hear it!

ADFS with a one-way trust

One of the nice parts about ADFS, is it’s ability to work throughout your trust realm.  Within MS IT, we have a single ADFS instance joined to our REDMOND domain in our main internal forest.  However, we have 7 production forests, with a total of 17 production domains.

Fortunately, the requirements for ADFS are fairly simple and intuitive:

• The user has to be able to authenticate to an ADFS server
• The ADFS server needs to have the ability to query the users domain, to read attributes to put into the users token.

Thinking about it like this, then it’s easy to see that with a full mesh of 2-way trusts between the forests, a single ADFS instance will work for users, regardless of which domain their account resides in.

Even the most complex systems work in PowerPoint

SCMDM Deployment

Been having some great discussions lately with the MDM product group.  They usually go something like this:  “But we didn’t design it to be deployed that way!” - “I know, but we don’t want all the features that you designed into it, so we’re deploying around those.” - “AAAAGGGH”

That may be slightly exaggerating, but not significantly.  You see, the product group designed and built this system, so that it has a gateway server that lives in the DMZ, and essentially acts as a VPN server for mobile devices.  Then there is a “Device Management” server (DM) which they want to have sit inside the internal network, so that when the phones VPN in they can get to it.  The DM is what reads policies from AD, translates them into phone-speak, does inventory of devices, config management - it’s the super-power in the system.  All of the other actors are playing a supporting role, and there are a few other components here, but these 2 are the important ones.

The reason that the PG is hating IT at the moment though, is because we have a basic disagreement in philosophy about mobile devices.  The Windows Mobile team has worked long and hard to make mobile phones a “first class citizen” of the network, as they say.  What that really means, is that they believe that a mobile phone is as secure, or more secure, than a typical user laptop.  IT on the other hand tends to disagree, and we think that although they are secure, and have different sets of features - the fact that a phone auto-locks in 15 minutes and a laptop doesn’t - isn’t sufficient to push the bar up to equivalency.  Now don’t misinterpret this to mean that phones are insecure, because that’s not true either.  What I’m really saying, is that “the way we manage remote users and their laptops” is more secure than the way we can manage remote users and their mobile devices.  It’s a relative statement, not an absolute by any means.

Of course, up until now, nobody has ever said that we need to think of phones as the same as laptops.  But the fundamental design principle for MDM was that they were considered the same - and now we’re getting tension because we’ve modified our MDM deployment based on our philosophy (not theirs).

For example, between the infrastructure engineer (me) and our security guys, we came to the following conclusions:

- Managed mobile devices are more secure than unmanaged mobile devices

- Managed mobile devices are less secure than managed laptops

- Unmanaged devices (mobile and laptops) are just evil and if we could undo the mistake that is Activesync and OWA without ruining the business, everyone’s data would be a whole lot safer

Since managed devices are safer than unmanaged devices, then it’s in our best interest to have them managed.  And, since they are managed (and safer), we can actually allow more sensitive data to be stored on them.  Along this continuum though, do we necessarily want any and all arbitrary data to be stored on phones?  No, and it actually doesn’t have to do with the phone either…we don’t want our data stored on ANY device that’s not protected.  Protecting the data is what it’s all about!

So for our SCMDM deployment, rather than allowing mobile phones to have unfettered VPN access throughout the entire environment, we’re dangling a carrot, in the form of “additional, useful, made-for-mobile” applications which only become available when the phone is VPN’d in.  Of course, that VPN connection terminates in our DMZ, which is where we’ve deployed both the gateway server, AND the device management server.  We host the applications through a mobile-web portal on our IAG servers. 

The result?  If your phone is VPN connected, then you get policies from the DM server, and you get the extra ju-ju from the applications which make your life easier.  If you turn off the VPN connection, no policies, and you’re back to surfing the ‘net without any additional access.

Did you see my blog? (let me e-mail it to you)

There is this fascinating trend internally at Microsoft.  Well…ok…maybe not fascinating, but definitely a trend!

A while back, faced with the “Mini-Microsoft’s” and “Scobles” of the world, the powers that be decided to set up internal blogs, where people could post things for other employees, without necessarily airing our dirty laundry to the rest of the world (what fun that would be, I have no idea).  Many of the managers have picked up on this, and periodically will post about something that’s going on in the org.

The interesting trend though, is that in addition to posting their blog - they also e-mail the content, usually with the subject line similar to “Hey, I’ve posted something new to my blog!”, to everyone in their org.

The part of blogs that I like the most, is the - “If you don’t like, don’t read it” - mentality that you can have.  This was one of the reasons that I moved my blog from TechNet to WordPress, so I could eliminate the expectations that every post had to be technical or about AD or something like that…It’s empowering to be able to rant, vent, or observe random things and then write about them.  But I wouldn’t ever send out e-mails to all of my friends telling them that I posted something new.  That’s what RSS is for…

and seriously, if I didn’t want to read the blog post before you sent me a mail…I’m most certainly not going to want to read it afterwards…

On death and De-Perimeterization

Two co-workers just published an excellent article in Network World describing how we “really feel” about network based access control’s.

Price is a security architect in MS IT, and Dan is an Identity Architect on the same team that I am.  Both are ridiculously smart guys, who (obviously) wax poetic.

http://www.networkworld.com/columnists/2008/050208-jericho-forum.html

Need a hook-up…please…don’t…be…offline…please

Sitting in Tully’s this morning, working on some documentation, when this whirlwind comes flying through the door, lands in the first available chair, and flips open the laptop.

While she’s obviously waiting for her machine to do something (log in, come out of sleep, I don’t know…)  I made the comment, “You look like you’re on a mission for a good internet connection…”

“Yeah, thank god for free wireless!”

Just as quickly, the laptop slapped shut, and out the door.

trustDirection Attribute Enumeration

Sitting in a coffee shop in Seattle - which is where I can usually get the most work done - and am helping a friend out by throwing together a VBScript that will enumerate all of the trusts, for all domains in a forest.  Not rocket surgery by any means, but one of the things which I thought would be nice to include is the direction of the trust, which is held on the aptly named trustDirection attribute of the trustedDomain object. 

Exploring a little bit through CORP, I was basically able to guess what the values meant, since I know what our forest/trust structure looks like, but since the attribute is just a number, I wanted to make sure that I had all of the options. I followed my instincts straight to my favorite search engine, and queried for the attribute, which promptly landed me on the MSDN page - previous experience telling me, that this is going to get me nowhere, because normally all you get is version and light information about the structure of the attribute.

So, much to my surprise, that down at the bottom in the Community Content section, Joe Richards had put the information which people would actually want and use.

So thank you Joe - for updating the documentation with the information which is actually relevant and useful.