Clayton Donley's Blog

Always exciting to see a successful new product launch. Version 1.0 is always the hardest and I think you'll agree that the team has done a really good job on this one.

Basically we've automated the entire process of Unix and Linux account centralization.

Yes. I know. It's been technically possible to do this to some degree for a while and we in fact are leveraging existing, standard technology as part of this offering.

However, if it was so easy to do already, why do nearly all of the customers I speak with tell me that they've not completed such a project after years of trying? The answer: it's actually pretty hard to do right. Or rather, it was.

If you're using an environment with Linux (RedHat, OEL, SUSE), Solaris, HP-UX, and/or AIX systems, you can follow some simple directions that will:

• automatically configure a directory server instance to hold your users,


• migrate your users from files, NIS, or other LDAP directories, and


• perform client configuration across your managed systems -- including SSL.

All of this is pre-certified end-to-end.

Find out more...

Technorati Tags: directory, identity management, LDAP, security

For those of you that don't like reading press releases and wonder what all he buzz is about our recently announced Service Oriented Security offerings, Tony Baer from OnStrategies has a great roll-up here.

Nishant Kaushik, one of our key architects, does a fantastic job of boiling down this announcement as follows:

SOS covers the four stages of an application lifecycle - development, deployment, administration and governance. With SOS, organizations can now centralize and externalize security solutions as part of a flexible security architecture. Recent identity related efforts like the Identity Governance Framework are also part of this architecture, providing the ability to deliver privacy-aware applications.

Certainly the key take-away for customers and those building everything from the next bank portal to the next Flickr is that you can get cohesive identity management as a service today, so you're better off crafting your value on top of these services rather than trying to do a better job with identity management fundamentals.

I'm in Seattle for my brother's wedding, so was unable to see Thomas' talk at RSA yesterday. I would love to get some email with first-hand accounts and feedback.

Technorati Tags: identity management, LDAP

Having just mentioned "The Cuckoo's Egg," I thought I'd share my first IT security experience. I started my career at a large enterprise on a team managing networks of servers and workstations from vendors like Sun, HP, Motorola, and the like. The events below took place in the early 90's.

User accounts were centralized using NIS (in some cases exported to files and distributed to individual machines) with home grown tools for doing everything from adding/removing user accounts to backing up servers.

Since we were a high-tech manufacturing company, we had many labs that contained specialized servers for testing. These specialized servers were generally wide open, with a large number of people holding privileged accounts (e.g. root). The lab machines were, of course, connected to the main network.

At the same time, many of the tools used on various servers required shared access, which was done through the use of group accounts. Since many of these tools were run by commands that would remote shell using that group account, it was typical for these accounts to allow direct access (i.e. without using commands like SU).

It should be pretty obvious after the last two paragraphs that we were set up for a train wreck. This train wreck was triggered by something unexpected:

Needless to say, someone at the company had apparently had an extremely bad experience with a dating service called "Heart to Heart". Rather than call the better business bureau or tell his friends to avoid the service, he (or she) decided to send everyone in the company an email with the simple phrase:

The email was sent using a group account on a Sun server running SunOS 4.0.3. The connection to that server was made from an open HP lab server. The connection to the open lab server came from another open lab server in another city and in another division.

All of the audit logs were enabled, but all of them simply logged that root or a group user had logged in and done some work. At no point was anything traceable to the user.

The result?

Because of the way the email was sent (large to lists, rather than bcc), large number of vacation mail messages were triggered that went back to the group account, which in fact had mail forwarding set up to the rather large group of people that had access to the account. This in turn triggered lots of other individual vacation mails, autoresponders, "bots", and so forth from every person on that list back to the same wide distribution list.

Within about 15 minutes, the entire email system was choking and it took hours to get things back to normal.

It could have been worse!

Ok, so technically the dating service itself didn't take out the network. We tightened things up significantly from that point on. I had no security responsibilities at the time and was not at fault, but the experience has stayed with me since.

If the person had been more upset with his or her employer than with a dating service, what untraceable havoc could have been caused? Probably a lot worse.

So I'll just leave this as a cautionary story to those of you who are in environments where only "the important systems" are under identity management. Lab servers, group accounts, and similar gaps reduce or remove accountability and can compromise the rest of your network.

Oh, and we can help. :-)

Technorati Tags:
identity management, security