Brian Puhl's Weblog

These postings are provided "AS IS" with no warranties, and confer no rights...WHEW...glad we got that over with, let's get to the good stuff now...

Blogs

Interesting SSID and Reusing Attributes

  • Comments 1
  • Likes

I bought a new truck a few months ago, and right on schedule (as the salesman promised), as I was coming due for my first oil change, I got a card for my first one free at the dealership.  Never being one to turn down a free deal, I dropped in the other day, handed over my keys, and directed to the lobby where the offered, "Free cofee, pastries, and wireless internet."  This is Redmond after all.

So sitting down with my laptop, coffee cup, and a donut, I fired up my laptop to synch my e-mail.  Viewing the available wireless networks, I almost laughed out loud when I read the SSID:

LJ Chev Cust Net - Ask Cashier for Key

99% of you probably just looked at that and went, "Umm, yeah...DUH!"  But both of the people in the office that I mentioned this to said, "Whoa, neat..." which by my statistical methodology made this blog-worthy.

So what does this have to do with AD?  It reminds me of a common question that goes through the AD discussion alias at work.  The details change, but the gist of it is always something akin to:

"I've got a customer/application/user that is asking whether there are any applications (MS or 3rd party) that use the drink attribute, they are creating a custom password reset portal, and need someplace to store the answer to the secret-question."

Three people just fell out of their chairs laughing, two of you did one of those "I can't believe it" head smacks, and there's one guy who just made a note to himself that he needs to update his portal application to use a different attribute.  THAT'S the guy that I want to talk to.

Reusing attributes is bad, each and every one has an intended purpose...well...ok, there are those pesky extensionAttributes, but let's not get picky...  If you're creating an application that needs to store data in AD, then go ahead and get an OID branch, and create one... there's a ton of documentation out there on how to do this.

Someone is going to say something about being so cavalier with the schema.  Yes, I understand that it's a one-way operation, and I always advocate doing appropriate testing before mucking with your production schema, but I've always been mildly disappointed at the level of FUD that Microsoft created surrounding schema extensions.  Caution and due diligence should be taken with everything you do in Active Directory.

Comments
  • HAHAHA. Great post. :)

    I think I field that question fairly regularly personally and in the newsgroups as well. I agree, don't reuse, first you tend to do bad things like jamming unrelated info into a misnamed attribute or start stacking info up in the attribute.

    I have one thing to say on the being cavalier... This is why you do it RIGHT!!!! Don't be afraid of doing schema updates, be afraid of doing them half-ass. Get a valid OID, don't use OIDGen or make them up. Look on the MSFT website and make sure that the oid and linkids and prefixes are registered unique for every vendor that comes to you with an extension. Question EVERY change you want to make, does it really make sense.

    On the flip side, App vendors, allow your customers to use different attributes. They may already have an attribute that does what you need in your app, allow them a mechanism to remap the attributes you use so they don't have to duplicate data...

    That's all for now. Again great post. I laughed at loud when I read the SSID part....

     joe