There is another great interview on Security Squared, this one focusing on SecureNet, a new Ensynch partner. The interview can be found here.
In the interview, Sharon J. Watson (interviewer from Security Squared) asks:
SJW: Eric had mentioned earlier he'd read my interview with Dave Hansen over at CA, and Dave really thought Active Directory should not be the authoritative source. He said that put IT in control of creating identities and that to him was a problem. He thought that responsibility should be backed up to HR and its systems.
I'll come back to this in a bit, but first SecureNet's Greg Thornbury has some great responses based on practical experiences:
GT: We've done some deployments where we've pointed to HR systems like Peoplesoft, SAP, things like that. We typically have found, even when we're doing that, a lot of resistance on the part of the end user to allow us to really connect to that production HR system. So when we have done it, we've typically done it through some middle connection or step. A batch process at the end of the day or an instance of that database copied out there that's not running in production.
First comment – this parallels what we see in the IDA deployments we've done. In some cases you can get great interaction with HR (my current customer is one of the rare few that don't mind working very closely with internal IDA) and in others you are a second class citizen and can only see a text file extracted nightly; delta's, forget it! I've even had customers where HR is outsourced so completely that they have no way to get regular automated extracts.
Greg continues with:
A lot of what we do as an integrator is speak to our client and do a lot of listening and find out what is the best authoritative source. In a lot of organizations, you're going to find that answer isn't going to be consistent. We're flexible. We've done it both ways. It's great to connect to HR; that's truly the originating point for a lot of that data. In other cases, it seems like HR doesn't keep up everything from an employee location standpoint the way IT does. In those cases, Active Directory may be the better source. At the end of the day, it's always the end user's decision. We try to help them and consult with them. We can look at different sources, so it doesn't really matter to us as long as it's the authoritative source.
Greg is being kind here to his customers to soften the blow a bit – in practically every case we've found dirty HR data in various forms. This goes back to one of the primary drivers for HR data – payroll. If I'm getting my paycheck and my benefits then I have no reason to talk to anyone at HR unless I want to file a grievance, change my address or change my benefits or deductions. In my experience, the number of companies that have mature HR self-service portals that employees actually use is quite slim. This results in primary identity and departmental information being correct but few are going to update phone number and physical location information here. For instance, my job code might identify me as a developer in Department 200 with a location code of 350, but that information doesn't always coincide with the actual location I reside at. In many cases HR may only care to identify the campus you are at but not the actual building, floor or mail-drop (your mileage varies widely here). What you end up with here is a partial disconnect from what HR cares to track versus what you need for a full PACS/IDA solution; it's an issue of fidelity here.
Greg makes a point earlier here:
But a lot of companies are using contractors now as well. In a lot of cases, the contractors aren't managed inside of Active Directory in the same way employees are managed. Typically we'll have several authoritative sources: one for employees and a separate authoritative source for contractors. We've also got solutions that tie in visitor management systems creating visitor credentials and in that case, you've got even a third authoritative source for where the visitor data comes from.
This is a serious hole in the "use HR only" approach and one we've seen quite regularly as well. Only on rare occasions have we seen businesses actually manage non-employees in HR; this has to do with what drives HR (keep reading). Hooking into multiple data sources means your business rules just became a lot more complex. Using Active Directory as the consolidated identity directory bypasses much of that.
Eric Rohleder adds later:
ER: Another nice part of connecting to Active Directory, since we're talking about physical/logical convergence, is the logical access is usually tied to Active Directory. So you go to Active Directory and deactivate an identity, you know in one step you're going to get physical and logical turned off at the same time.
What Eric is describing here is important, the fact that you have an abstraction layer between what HR says and what logical access is enforcing. If I need to walk an employee out of the building, do I wait for HR to process the paperwork so that the termination date field is populated, or do I just disable their AD account? In reality what happens is the manager makes two calls, one to HR to start the process, and one to the administrators to terminate access immediately. HR is less concerned with updating their database than they are worrying about following all of the complex termination processes in order to avoid any wrongful termination lawsuits. It could take HR days to process the real request, so which would you rather rely on?
HR or AD?
Obviously you can make either work, but which is better? The answer is that it depends. When the question is framed from the point of view of an IDA implementer our answer is always "THE authoritative source, no middle men", so when implementing an ILM solution we want to talk as directly as possible (and as often as possible) to HR; however, that's because we're responsible for all of the business logic that Eric and Greg allude to and we're built for connecting to multiple data sources. We are responsible for building the rules for when and how the AD accounts are created in the first place, therefore, the same question, from a physical security perspective is best answered as "AD", with the proviso that some sort of IDA automation (like ILM/FIM) is responsible for driving identity provisioning and deprovisioning. Once you have a robust process driving the identities then physical access integration becomes possible as it becomes another client of the directory and some very nifty ROI can be achieved by levering the existing investments in IDA. In short, when IDA and PACS work together you can truly realize convergence with a single identity.
What about Directory Chaff?
With any directory you're going to build up a small amount of detritus; orphaned accounts in addition to valid accounts like service accounts, administrator accounts, computer accounts, etc. As Greg points out, there are easy ways to filter out much, if not all of that with SecureNet's solution, but only a good IDA solution is able to keep terminated and inactive users out of the system and if PACS is connected to AD then that investment pays off without any complex business logic changes on the physical security side.
Consider another problem, a recent customer of mine has a requirement that all employees maintain active AD accounts in order for them to come back and access self-service W2 information from HR up to 6 months after termination. In HR, this person is terminated, with a termination date, and a status indicator; however, in AD I can maintain an active account because we've built that business logic into how ILM handles terminated accounts coming from HR. If that requirement changes to 9 months then we have a single very simple change to make within our ILM configuration without any re-coding of flows. Now this presents a small challenge to the "use AD as the source" as you'd now have a terminated person with badge access, right? Nope, enter SecureNet's solutions for RBAC. They have the ability to either map directly against AD group or to build roles based on attributes of a user. In either case, since we control the data present on the user and their group memberships through ILM, we remove the users from any physical security based groups or modify the user attributes such that the derived roles in the PACS system remove badge access while the AD account remains active. What you gain here by using an IDA driven AD is flexibility.
Getting Identity data into your Intelligent Controllers
SecureNet uses a really nifty product for automating the data import from sources like databases, flat files, or AD itself. This is not something I would turn to ILM or another identity provider to attempt to do given the antiquity of the protocols used to communicate with even modern intelligent controllers. The good news here for companies that have Mercury Security (Lenel's On-Guard, Open Options, Honeywell, RS2, Arinc, and Indenticard to name a few) based PACS is that this system is fully compatible with some minor migration efforts required; that means you keep all or most of your hardware (controllers, readers, panels, etc) and just upgrade the software. SecureNet specializes in this sort of physical integration and Ensynch is happy to partner with them to extend their reach on the IDA side. Ensynch just completed an internal conversion of our PACS using SecureNet and are extremely happy with not just the results, but the possibilities of finally converging physical and logical access…and yes, we're using AD as the source!
How Do I Converge?
Contact me and let's talk – we're happy to connect you directly with SecureNet or feel free to contact them directly if you have questions regarding physical security. Ensynch would be happy to help you get ILM/FIM implemented so that SecureNet has the best possible chance in leveraging AD directly.
