Blog-and-a-Haircut

The End is Near

2006-12-31T13:32:00Z

As 2006 winds down, I’m loathe to be like everyone else and reflect on the past year and wallow in the glow of yet another year gone by. Why? Because there is so much I haven’t done and I feel like I’m slipping further behind, that’s why.

As an example, this blog: I have not updated this blog with witty, insightful or interesting tidbits. That’s a shame, because many thoughts have come and gone, but I have not capitalized on them yet.

Exciting things to do: I have not yet played with or otherwise installed and reviewed Microsoft’s Vista. That likely makes me the last techie on the planet to have not. But I am also one of the few that doesn’t have the hardware to do so. I’m ashamed to say it, but much like a street walker (aka “hooker”, “whore”, “consultant”) I usually have my toys paid for by my employers. My current employer doesn’t really afford me the opportunity to have that kind of hardware at the moment. Sure, I can ask for something and likely get it, but it’s not material fast enough to get the full ride of the platform. As such, I haven’t used it since beta 2.

Microsoft’s Longhorn is another item I haven’t yet cracked that tape on. That’s not good because that’s an up and coming server OS that deserves more attention. Sure, I’ve been deeply immersed in R2, but it’s just not the same.

So….what have I been doing? I hate to admit it, but I have been looking back and what I see is a lot of busy work. I’ve been busy making inroads into areas that desperately need attention at my current employer. Years of politics and divestitures and mergers have taken their toll on the infrastructure. There’s a lot of fragmented talent and the infrastructure reflects that. I’m working hard to sow a lot of that up and convince, help, push people to move in a more positive direction. That means ripping some things out, re-thinking others, and avoiding still others. That takes time. Especially when I’m just a lowly hands on, in the trenches kind of techie at this company.

Virtualization – man I love that stuff. Very handy and solves a myriad of issues. Of course, it opens a lot of other doors that might be dangerous, but I love it.

Monitoring – well, it has to be done. Not very sexy, but boy does life suck without it. Even worse when you don’t realize what life is like with good monitoring and you think you have it already.

Email – that’s a passion of mine, but I’m hands off currently. I’m biting my nails realistically.

School – hey, it’s always nice to keep the mind sharp. So I decided to return to school and see if I can pick up some business classes. This is a first step on a long journey, so don’t look for anything earth-shattering any time soon. Just stay with me on this one.

Exercise – like many of us in this field, exercise comes at some other time. I miss it. Before shoulder surgery many years ago, I was running 5-7 miles a day and then going to the gym etc. Previous life of course, but I miss it and I’m starting to get back into it. Slowly because I really don’t want to pick up any undo injuries. I’ll let you know how that progresses.

Writing – I keep trying to write on a regular basis. Goodness knows I need to improve it. Let me know how I’m doing if you have any suggestions (return to my day job has been taken; please pick something else J

I haven’t mentioned my family in this, but let’s leave it as an assumption that I devote as much time as I can to my family. My wife is also going to school these days and I am committed to supporting her in that endeavor. I’m also committed to supporting my kids in their endeavors. That doesn’t leave a lot of time as you can imagine.

What’s ahead? As if I need more right? Well, I plan to look into some of these open source projects. I think it might be time I take a closer look if I can find the time to do that and look at Longhorn. I’ll keep you posted on that as well because I think it could be a great learning experience and can really enhance my career path in the sense that I’ll get that better learning. All of that will have to wait until after my wife and I finish our missions trip in February. She’s a dental professional and I work with computers – turned out somebody needed us both at the same time.

So as 2006 ends, here’s to wishing you a happy, safe, fulfilling and exciting 2007. No put down the mouse and go outside. J

History Repeats Itself

2006-10-05T14:56:15Z

I was having a conversation the other day with an IT security team member at a friend's company. He was talking about some IdM processes and how it was odd that an error occured in the provisioning system. He and I have had a few conversations about the consistency of the directories in use and how that could be a problem in his environment. In addition, there have been reports of tools in use that cannot understand organizational unit structure. That's why the current implementation of Active Directory is using such a flat model for the users even though the single domain design/multiple line of business business model (distributed IT aligned with line of business) they have just screams that it should be a more delegated model.

Because the current policies and processes in use have no provision for the removal of accounts, the current lifecycle includes a disabling process (I mean that figuratively as well as literally) where the electronic identity is disabled vs. being removed from the directory store. Presumably, this is because of some legal requirement, but he has not been able to confirm that yet. The company currently employs a system where every consumer of the electronic systems are represented by a unique identity number. This is still fairly new to the company, but every warm body that has access to a corporate computer asset has been issued one and uses it for one access or another. Most users are forced to use at least two identities but thankfully there is a password synchronization mechanism in use that at least helps reduce some of the help desk calls.

The issue he was describing was that of a user, Jane Smythe that had worked at the company as a full time employee. She left and came back as a contractor. She left again. Then another Jane Smythe came to work in that same department for the same manager. Then the original Jane Smythe came back to work as a contractor again (really, HR should get a handle on retention!) When the original Jane Smythe left and came back, the same unique numerical id was assigned. Well, not each time, only when in the same role (contractor vs. FTE.) What's wrong with that, you ask?

Perfectly normal account lifecycle scenario from what I can see too. However, because this company provisions the accounts in Active Directory using a distinguished name that includes the user's first name and last name, there was a collision when the administrator tried to re-animate the original Jane Smythe account. That's because ADUC and the way our MIIS system is configured, builds the distinguished name using the displayname value. That makes the (R)DN look like this:

cn=Smythe\, Jane,ou=SomeBusinessUnit,ou=AnotherHigherBusinessUnit,ou=corporate,dc=domain,dc=com

The problem of course is that there can be only one cn=Smythe\, Jane in that relative path. You could have additional cn=Smythe\, Jane 's but they'd have to be in some other cn or ou. In this organization, you would also have a problem if you tried to disable the electronic identity because the user id's are put in the same container for neatness. Distinguished names would collide if that happened.

What's the solution? Remember how I told you that every person with computer resource access is given a unique electronic identity that they use to logon to the network? The solution is to create the electronic identities with the cn equal to 'uniqueElectronicIdentity'. For example, instead of using

cn=Smythe\, Jane,ou=SomeBusinessUnit,ou=AnotherHigherBusinessUnit,ou=corporate,dc=domain,dc=com

you would use

cn=12345678,ou=SomeBusinessUnit,ou=AnotherHigherBusinessUnit,ou=corporate,dc=domain,dc=com

If you use this system, then when a user is moved between containers and organizational units, there won't be any collisions as long as you follow that formula. But as a best practice, let's not stop there. Ever been tasked to integrate an application that uses LDAP calls to identify and authenticate users? Ever want to use Active Directory for that task? If so, then setting the cn this way is almost a requirement.

In most environments I've seen, the distinguished name of the users follows no particular scheme. Often this is just because Windows administrators historically have not had to worry about that value. That was the domain of LDAP administrators. Instead, users are only concerned about their "pre-Windows 2000 logon name" a.k.a samaccountname. When LDAP and Windows collided in Active Directory, administrators typically weren't interested. Over time, this becomes more of an issue.

The problem is that if you don't make these consistent, then unless the application was written to search for user information in an Active Directory you'll have to instruct the user to logon with a credential like this

cn=Smythe\, Jane

and as an added inconvenience, you won't be able to move the user objects around in the directory for management purposes. That's very restrictive in my opinion!

Since the user is already conditioned to know themselves as "1234562" when they logon to Windows, it makes sense to make their LDAP logon name the same right? Right. If you make the cn the same as the samaccountname then by default the distinguishedname will be the same as well.

But wait there's more....

What about their user principal name? Should the user have a different value for that as well? I don't think so. In fact, in older versions of Exchange, you would have issues with Outlook Web Access if the samaccountname and upn value left hand side were different. If you also didn't have the mailnickname match one of the proxy addresses, then you had problems.

The easiest solution to the problem my friend sees is to provision your security principals so that the samaccountname, mailnickname, cn, and left hand side of the user principal name are the same value. Making these four attributes the same unique id will result in no collisions, easier integration with LDAP applications, less confusion for users, and a more consistent directory for your developers. I didn't mention that earlier, but you'll have a much easier time programatically managing and reporting on your Active Directory if you make your directory consistent.

If anyone's interested, I'm sure I can blog something about how to go about making an existing directory consistent along these lines. I'm interested if anyone sees anything different than I've written about. But I'm sure I'll see this same behavior many more times in my career. History does repeat itself.

WINS-WINS Situation

2006-09-12T14:03:00Z

Wouldn't it be nice to get rid of WINS in your environment?

But have you stopped to think about why that would be a nice thing? Could it be because of the years of plaque-like build up of erroneous records in your WINS databases? Is it because of the many people with varied thoughts and ideas that have "owned" WINS in your company over the years?

Is WINS just a victim of its own success? Or could it be because if you must install WINS you now have to maintain two name resolution environments that are similar yet different if you deploy Active Directory?

I suppose it could just be because there hasn't been a large amount of tools available to help troubleshoot it. I mean, it pretty much worked or didn't right? If it didn't, you had to open a fat GUI client that seems to always take much longer than you feel is necessary.

During all the years I've dealt with WINS, whether in design, deployment, troubleshooting or just plain trying to understand how it's deployed at a given client site, I've always had the following thoughts about it:

1) It's a pre-cursor to the dynamic DNS we know and love today whether in the Windows or opensource environment. Ok, that's a relatively new thought comparatively speaking.
2) It really does do quite well, although it can't scale nearly as well as DNS.
3) There are just no good command line tools to help troubleshoot. At least in DNS there's dig or nslookup or even ping with the -a switch to find particular addresses and corresponding information.

But this evening, while working on a separate WINS issue, I ran across this:

http://support.microsoft.com/kb/830578/

Wow.

Want to query for a specific name? Yep, it can do that.

Want to query for a specific record type? Yep, it can do that too.

Most recently, I was interested in enabling replication between two environments that were previously only connected via DNS so that we could work in a trust relationship. The source domain is a NT4 domain and the target is Windows 2003 running at 2003 Forest Functional Level (FFL) and Domain Functional Level (DFL). The source servers are located in Australia as are the target domain controllers. But I'm located in North Carolina (USA) and I'm not fond of remote control over high-latency connections if I can help it. Also, the WINS topology is such that the records have to go from the source domain to the target domain in the local site, then to a central WINS server in a different site and then back to my local WINS server before I can start. How to watch the progress so I know it's complete? Before I would have had to enumerate the entire WINS db. Yikes. Now, I can instead use this command line tool to query the WINS db for my needed records like this:

nblookup /s server.sourceDomain.com.au /x 1C targetDomain

That returns the following:

server.sourceDomain.com.au resolved to 10.1.1.1
Default Server: 10.1.1.1
Recursion is on
Querying WINS Server: 10.1.1.1
NetBIOS Name: target
Suffix: 1C
Name returned: TARGET
Record type: Group

IP Address: 10.1.1.65
Record type: Group
IP Address: 10.1.1.65

Pretty nice. Now I know that the records exist on that server and all I need to do is change the server I query from server.sourceDomain.com.au to the targetDomain WINS servers in the chain and I can find out the information I need. That's quite a time saver in my opinion and a tool that was long overdue.

There are many other options available. Check out the kb article for more information and other command line options.

It’s a Sad Day for ISS

2006-09-01T13:45:00Z

I was reading this article, http://www.informationweek.com/showArticle.jhtml;jsessionid=B35NVR10CV1JYQSNDLRCKH0CJUNN2JVN?articleID=192300430&queryText=iss+ibm and was struck by one of the comments made about how positive and what a good thing the purchase is for the customer now that IBM can offer a more rounded service.

If you haven’t heard, IBM bought ISS. The big news however is that they aren’t putting ISSs intellectual capital (i.e. the people that write the software) into the software division. Nope. IBM is going to put the company into the IBM Global Services division. The thought seems to be that if they do that, then they can offer a more rounded, and therefore more appealing set of services to their customers.

According to the spin, by making this sacrifice, IBM puts itself into position to help, you Mr. Customer.

Ok, if you sell software, you have to spin your products in a positive light. I’ll allow that. But what gets me is that you pretend to be able to offer high-end resources at reduced costs utilizing “economies of scale” economics. That’s where I take issue.

Think about it. If you’re an outsourced services sales person, your job is to convince Mr. Customer that you can do the job (whatever the job is) better and for less money than he’d otherwise spend. IT is all about intellectual capital (otherwise, it’s just one’s and zeroes, right?) To do that, you’ll give him better job resources than he can otherwise bring to bear thereby alleviating him of his burden of managing high-end technical people and of paying those salaries and increasing the drainage of his bottom line to those blood-sucking IT peop… well, you get the idea

If you’re IBM, you’re telling your customers that with the acquisition of ISS you now possess the magical mix of technology and personnel to offer a security scanning and patching service to go with your hosting services that you were lacking before. And, if you buy today…Wait, I get ahead of myself.

But the issue comes up later, after you’ve let your “high-priced” people go. You find out that IBM has taken that highly talented resource you’ve gotten used to seeing and re-focused her on another client’s issues. “But, we’ll take care of you and we’ll fulfill our agreement – to the letter.”

IBM’s pressure in this relationship is to lower costs to make the outsourcing more equitable for them. They are in business to make money after all. The manifestation of that is that for the first 6 months, you’ll see the highly technical people diligently working on your issues and bending over backwards to make you happy. Then, those people will be moved to other projects or will otherwise move on to “be focus on their family life.”

Where does that leave you, Mr. Customer? You’re in a cycle where you now depend on your outsourcer. And now that you’ve gotten rid of that high-priced IT shop and replaced them with a few mid-level managers, you have some people that can manage your issues and give your business competitive advantage right? Hmm…. Really? Might want to think about that.

Don’t get me wrong. It might make sense to use such a tactic for your business. But at least you can go into knowing the pressures that each side has and not fooling yourself into thinking that you’ll have the high-end technical resources for less than you’d otherwise spend. And you only wanted your business to be successful at the lowest possible price! They want to sell you a service that pays a recurring annuity and they want to lower their costs year over year.

Is ISS a good purchase for IBM? I don’t think so. IBM couldn’t make it work before when they had their own in-house scanners and pricing models. I doubt they’ll be able to make ISS work in the Big Blue machinery. Of course, they didn’t ask me how to build their credibility now did they?

A Rose

2006-08-29T16:24:00Z

What’s in a name? That famous question makes me wonder if names are really very meaningful or even interesting. Names sure are important to the proper working of networked devices. No getting around it, you must have solid working name resolution if you expect to have a working implementation of <insert your application or service here>.

Common knowledge? I would have thought so. But I see this being overlooked all the time. I was talking to a friend just the other day who was complaining of some server issues. Part of the problem is that the legacy name resolution situation is absolutely choking them. They were divested a few years back but retained a lot of the stuff that they had when the divestiture took place. Cleaning that up is a real trick. To make it more interesting, they’re in the middle of a migration from the legacy environment to a new Active Directory environment. Oh, and just for icing on the cake, they’re also changing network blocks internally. Nothing but net!

Detour- what is included in the name resolution service? For me, I define the name resolution service in most enterprises as NETBIOS name resolution, DNS, LMHOSTS files, HOSTS files, and broadcast query. All of those individual components together make up my name resolution service. You’d be surprised how many people are so focused on one component of name resolution that they totally forget how they interact and build on one another. Without some advanced planning and thinking, this can become a mess that nobody can troubleshoot in a reasonable amount of time. Not good for your business.

Most of the issues reported don’t appear to be related to name resolution; on the surface at least. Time-outs talking to servers, intermittent connection issues, applications that work one second and not the next, etc. Can all the issues be blamed on name resolution?

The problem is, you can’t conclusively say no to any of those issues. My argument is that it’s worth the pain of fixing every bit of those issues. So far, I’m a minority in my thinking. Fortunately, I’m used to that. I’ll also know the next time some strange, head-scratching issue comes up, that I’ll get a head start if asked to help troubleshoot. I’ll just look to name resolution first.

Let's Get This Party Started!

2006-08-18T07:42:00Z

Sometimes I feel like a dinasour in this world. Sure I'm large, scaly, green and slow to move in cold weather, but what I'm referring to is the time it's taken me to start blogging. I've been in the business of communications for over 17 years now, and this will be my first blog. Shame on me.

Anyhow, I'll be gathering random thoughts, ideas, and other things that are of interest to me that I think might be of interest to you, the reader. My hope is that at least once a month you find some useful tidbit here on the blog. If you don't, or if you would like to see something different, I would really appreciate it if you'd keep your comments to yourself (just kidding! I thrive on feedback. It's the only way to improve what I'm doing, and that's the main reason I even think it's worth sharing ideas in the first place. PLEASE send feedback of any kind.)

Happy surfing!