Help me slay the software octopus

June 2, 2007 7:38 PM

I just started a new job, and am astounded that the company seems to use a different software app for everything. I've got a variety of different (unique) username/password combos to try to remember. I'd like to suggest to them to find software solutions to combine some of these systems. Lets begin with the list...

The following software items are all things I have to logon to seperately---or use seperately...

Email
Timeclock
Phone/Voip logon
Customer ticket/request tracking (Filemaker)
Windows domain logon
Unix logon
Intranet (internal) Wiki
Intranet (internal) bulletin board
Intranet (internal) request tracking system
Jabber IM client

I know some of these systems are separate by design, and/or cannot be combined... but I'd like to hear ideas of creative solutions to minimizing the number of logons needed. In a perfect world, I'd combine the internal and external ticket/request tracking systems. I'd also combine the timeclock with the phone/badge/security system.

What I'm looking for are software solution suggestions ... that would provide the things above, help make us more efficient,etc. For example... ditch Filemaker and get a new CRM system (thats what they are called?.. yes?...) ... OR ... wipe and rebuild our intranet with a content management system that includes bulletin board and chat/IM client.

posted by jmnugent to computers & internet (18 comments total)

The organization I work at uses Lotus Notes for most of this stuff... it's basically awful. Very very slow, and requires a massive server structure to run in a large organization. However, it's a single logon.

Another consideration you might make is purchasing an Identity Management software package (e.g., Sun, IBM). They usually cost a couple million bucks, but many of these products can integrate into existing systems.

Finally, most things will use LTPA (usually LDAP)... and if you have Active Directory, that's probably the way to go. The UNIX stuff may be a little tricky to switch over to Active Directory authentication, but many versions come bundled with the ability to do LTPA (I know AIX does), and it has been done on Ubuntu.
posted by synaesthetichaze at 7:54 PM on June 2, 2007

There are several solutions that are in place in higher ed, where we can't get professors to set one secure password, much less twenty.

The current front-runner is Shibboleth. My campus has CAS implemented.

The important key throughout most of these systems for YOU is going to be the LDAP interface - Lightweight Directory Access Protocol. Having your SSO be an LDAP authentication server will allow windows, linux, jabber, the wiki and bulletin board, and other miscellaneous systems with LDAP auth modules to connect.

Oh, and even the systems that don't have password access can still be "ported" between. We had users set their passwords through a single sign on interface that could also export a shadow file and other password formats for Unix (dynix/ptx, ack!), our telefony system, and the front door keyless entry authentication system.

Be careful having just started ... proposing a serious change in the Way Things Are Done might brand you as a troublemaker either with management or the grey hairs in IT.
posted by SpecialK at 7:58 PM on June 2, 2007

synaesthetichaze, Thanks for the suggestions.

The company is a relatively small local ISP (approx 50 employees total).. so I doubt they'll be willing to even entertain the idea of spending $big$ on any Identity Management package.

The company has a strong Unix background and only recently (about a year ago) finally implemented the Windows domain controller, ... so I doubt much will be done in the Windows/AD arena...(even though i'd fully support it.. as my 15year background is all in Windows domain/network management,..I could easily help them do that)
posted by jmnugent at 7:59 PM on June 2, 2007

SpecialK
"Be careful having just started ... proposing a serious change in the Way Things Are Done might brand you as a troublemaker either with management or the grey hairs in IT."

I am a little worried about that,.. but the company seems fairly innovative and open minded (they survived the dot-com implosion).. All I really want is to find ways to improve efficiency and put $$$ to the bottom line that will hopefully translate into more profit sharing. I cant see how management would be againest that.
posted by jmnugent at 8:01 PM on June 2, 2007

Shibboleth is pretty cool, and something I had forgotten about (even though we use that too!).

SpecialK, can you tell me which product does this:

"We had users set their passwords through a single sign on interface that could also export a shadow file..."

That sounds pretty neat. This wouldn't be too difficult to put together in perl (if the shadow file uses DES), but I'm wondering how it's done with an enterprise app.
posted by synaesthetichaze at 8:11 PM on June 2, 2007

Oh, a final suggestion... this is specific to UNIX and won't solve any of your system-integration problems, but... if you have a network with any more than, say, 25 UNIX boxen, it will drive your users crazy to change all of their passwords every month (or whenever). A nice solution is to implement SSH keys and configure SSHD to look for key-auth first, and only prompt for a password when it doesn't find an authorized_keys file.
posted by synaesthetichaze at 8:18 PM on June 2, 2007

Instead of pushing for changes to company wide systems how about using something like password maker instead?
posted by rdr at 9:00 PM on June 2, 2007

Throwing out the systems is laughable, unless A> the systems are otherwise bad at what they do, or, B> there's no way to get them to use a unified system AND C> experienced workers are losing a _significant percentage_ of their day to all the logins.

I agree with your idea to try to get them using a centralized authentication system. Even then, you should be pretty scientific about figuring out how much productivity is lost with the current system before you propose spending a significant amount of time on this project.

Side note: a single program is going to suck. Use multiple tools, each doing what it does best.
posted by blenderfish at 9:35 PM on June 2, 2007

Yeah, a per-client password management program which can fill out the forms would probably fit the bill, without changing the central system.
posted by blenderfish at 9:37 PM on June 2, 2007

As for remembering so many passwords, KeePass could be helpful.
posted by liesbyomission at 9:57 PM on June 2, 2007

Shibboleth is great, but it is primarily used to allow external access (trust) to your own resources. For internal SSO with a trusted authority, CAS is the way to go with web applications.

The problem that a lot of applications face is that pure authentication is one piece, whereas authorization within the application or resource is a whole different picture. You'd be hard-pressed to find popular applications today that will not use LDAP/SSPI/Kerberos etc. to implement single user/password combinations. The problem is that most applications require subsequent permissions that could be handled a number of ways.

Higher Ed focuses heavily on roles or groups (or a combination of both) and application level permissions. You're ability to customize home grown or vendor applications will definitely affect the extent that you can achieve the single user/password paradise.

My recommendations:
You already have a domain. This is usually managed by Active Directory. AD is effectively an LDAP-enabled service and if you research the applications you mentioned, you will probably find hooks for most of them to authenticate users.

If they're web-based applications, either ask the vendors if they support CAS or modify them yourself to support the service (it's not that difficult -- they provide client libraries for a lot of languages).

Finally, doing this yourself is impossible. First and foremost, state your case to your boss, your bosses boss etc. and find someone who will champion the change. For both security and user convenience, SSO and single user/password initiatives are well worth investing in. The problem is that most people either don't care, or just accept things for the way they are.

Sell, sell, sell!
posted by purephase at 10:18 PM on June 2, 2007

Yes on the LDAP to AD. This way you could at least harmonize your Unix (pam_ldap) and intranet passwords (mod_auth_ldap for Apache. Email too, depending on what it's running on. Jabber looks to have LDAP integration as well. Phone/VOIP maybe, with the same caveat as email.
posted by rhizome at 10:27 PM on June 2, 2007

Set up an LDAP server, use P-Sync to sync the LDAP with your AD server. Point your unix boxes at LDAP for authentication, pam_ldap would be a logical choice for linux and solaris.

Most of your other packages should allow LDAP authentication, if they don't you can always hack them up, or ditch them.

Ignore all this crap on here about having the unix boxes export shadow files and all this other nonsense like key only authentication, just have them authenticate against LDAP.
posted by voxpop at 10:28 PM on June 2, 2007

Nah, no syncing or anything is necessary, for awhile now pam_ldap has been able to auth against Win2k+ directly.

Filemaker is likely a no-go for any auth, but it'd be easy as pie to convert it to a web-based database and ditch Filemaker (as attached as people get to it...).
posted by rhizome at 11:21 PM on June 2, 2007

I recommend synching between LDAP and AD because you will inevitably have applications that can only authenticate using real LDAP, not AD's mangled version. Might as well have a lowest common denominator in place.
posted by voxpop at 5:09 AM on June 3, 2007

voxpop's implementation is probably the easiest in the long-run, since, as s/he says, AD isn't pure LDAP. Inevitably you will run into something that can't use AD's version of it. Just about everything can authenticate against real, pure LDAP though.
posted by synaesthetichaze at 6:48 AM on June 3, 2007

I have successfully setup over 20-30 enterprise applications to use LDAP-auth off of AD. Despite a few glitches, I have yet to encounter any major issues.
posted by purephase at 9:11 AM on June 3, 2007

Purephase, I've had huge issues trying to get some LDAP systems that don't want to speak AD's mangling and that are closed-source vendor solutions (i.e. our spam controller) to work with AD. We currently mirror AD with OpenLDAP and a conversion script to make up for that.

"We had users set their passwords through a single sign on interface that could also export a shadow file..."

That sounds pretty neat. This wouldn't be too difficult to put together in perl (if the shadow file uses DES), but I'm wondering how it's done with an enterprise app.

Actually, it's a perl web script on the intranet. Everyone changed their passwords on the intranet -- this also helped us eliminate helpdesk calls when people forgot their password and needed us to change it for them, because we implemented alternate ID forms such as a workstation on each floor with a thumbprint scanner and alternate questions -- and when they changed it, the systems that couldn't authenticate via ldap were pushed a fresh password file with (in this example of an archaic unix without PAM) the password for that user search-and-replaced with the new DES encrypted passkey.
posted by SpecialK at 9:38 AM on June 3, 2007