Slashdot Mirror


Ask Slashdot: New Employee System Access Tracking?

New submitter mushero writes: We are a fast-growing IT services company with dozens of systems, SaaS tools, dev tools and systems, and more that a new employee might need access to. We struggle to track this, both in terms of what systems a given set of roles will need and then has it been done, as different people manage various systems. And of course the reverse when an employee leaves. Every on-boarding or HR system we've looked at has zero support for this; they are great at getting tax info, your home address, etc. but not for getting you a computer nor access to a myriad of systems. I know in a perfect world it'd all be single-sign-on, but not realistic yet and we have many, many SaaS service that will never integrate. So what have you used for this, how do you track new employee access across dozens of systems, hundreds of employees, new hires every day, etc.?

7 of 87 comments (clear)

  1. Lastpass? by shri · · Score: 2

    Can you use something simple like the group version of Lastpass / setup their accounts and manage their passwords / revoke access?

  2. Re:In Theory - Thor by quetwo · · Score: 2

    Oh, it CAN be done. You just have to have somebody on staff who is an expert at RADIUS, LDAP, AD-AUTH, Kerberos, OAuth and probably a dozen other protocols that deal with authentication and authorization. Oh, and then a proper security audit because if you do it in house, are you sure that you can't drive a MAC truck through it?

    Having done the ROI estimate on such a project, we couldn't do it. And this was for a company that had at least standardized on products that use RADIUS and LDAP for all things they offered auth for.

    If it was easy to do, the list would include hundreds of products -- many of them open source. That should give you a clue.

  3. LDAP? by guruevi · · Score: 3, Interesting

    Just use a centralized solution that is configured to give access and authorization to assets, they exist, it's called LDAP and you can plug whatever the hell information you want in them, even the HR-only information (such as tax records etc). You then just need to make sure your roles are defined within your organization and HR knows about which roles to give to a person.

    If you're talking about giving people root/wheel access to certain boxes even when LDAP is broken, then you can still use LDAP as a source to feed into eg. an ansible/puppet script (or whatever configuration management system you decide to use) that runs every few minutes/hours/days and inserts/revokes access for those sysadmins.

    --
    Custom electronics and digital signage for your business: www.evcircuits.com
    1. Re:LDAP? by jon3k · · Score: 2

      I wasn't convinced until I read your name, but now I'm a believer.

      In all seriousness, you're correct. I've found in the real world you're using a combination of Active Directory (or some other LDAP) along with web based applications, and maybe even some compiled applications running locally. Some are behind the firewall, some aren't. You really need something that can support SAML along with form-filling that will also sync with AD to really cover the whole gamut. And even then some of it will be a manual process (eg that website that won't save passwords and doesn't support SAML).

      It's a big complex problem and no one has solved it 100%.

  4. Re:Lots of ways by LDAPMAN · · Score: 2

    "Set up like" is a horrible model. It leads to over provisioning of access and poor governance.

  5. Re:Competency by jon3k · · Score: 2

    Name three that are good.

  6. Re:As much as I hate to mention the "O" word ... by mjwx · · Score: 2

    It wasn't even *close* to cheap (either in implementation or ongoing support) but we added OIM (Oracle Identity Manager) to our existing Oracle suite of products

    We're an University of 30,000 students and 5,000 staff and we're getting rid of OIM because it cant do anything properly. After 3 years and literally millions of dollars it still cant communicate with Exchange, not only are we still employing the same number of people to do account provisioning (approx 14,000 new accounts per year) we're also employing a large team of developers who spend more time rolling back failed changes than developing new ones (jury is still out on whether this is a good thing). When Oracle recently turned around and said we needed to license another product to get Exchange connectivity it was the straw that broke the camels back.

    Not only this, Oracle is adamant that it cant be virtualised using VMWare. This means we need to keep around massive amounts of iron for the two times a year we do student intakes.

    Not only is OIM not even remotely close to cheap, it's not even remotely close to functional.

    --
    Calling someone a "hater" only means you can not rationally rebut their argument.