One of the things I’ve been investigating for the new Domino infrastructure rollout that I am heading up in my new job is ID management. Most places that I have worked at before have never really understood the importance of ID management. Certifier ID files and passwords and given out to whoever needs them, local helpdesk staff are shown how to create user id’s and id files get lost etc.
In Notes 4 the escrow agent was helpful and easy to implement, setup a user or group called ‘Escrow Agent’ and all ID files that are created would be sent to that user.
In R5 they expanded upon that with ‘ID Recovery’. Special information was embedded into the certifier ID file and then any ID’s created from that ID file would have the information passed on to them. On bit of this information was a user that would receive a copy of all ID files whenever they changed. There were problems with this, like users being able to cancel the send.
In ND6 they improved this yet again and it’s nearly getting to the stage where it is easy to deploy. The recovery information is now stored in the NAB, the end users don;t need to be sent the recovery info it is automatically picked up when they log in, the bit that sends the changed ID files to a central location now happens in the background.
So why do we still need ID Management systems. Well I think the answer is easy. It keeps the certifier ID files out of the local administrators hands, you have more control over how the users are setup and it assists with keeping SLA’s in a centrally managed system.
So far I have evaluated two ID Management systems, iDM from Centric and GSX ID Manager from GSX. Of the two systems I think iDM is the better, it is 100% notes based which I think is really important because the GSX application needs a small executable to be periodically run on the server to do the work. iDM also seems to have a lot more features in helping define who can request and authorise new ID creation and help ensure that any ID file that is created will conform to your standards for that office, country, region or even company.
I’m sure that there are more ID Management solutions out there and if you know of any more then please feel free to mention them in the comments so I can evaluate them also.
So, do you use ID management or do you hand out your certifier ID files?
The Cert IDs are attached to profile docs in the DB, but only we level 3 administrators can see them.
Hmmmm… you mean, you’ve got profile docs in the app that have ReaderNames? Do they replicate? Do local admins have physical access to servers? A quick local file copy of that, and I’d have full access to profile docs everywhere.
Your right Nathan, but did you know a better solution…..?
Check the cross certify system on the openNtf, you have the same risk.
As Justin, i’ve create a registration process for some customer, and I put the cert id on a shared (but protected) drive, and the application make the mapping automatically.
This is not 100% safe, but if you mix the security settings, you can reduce the (bad) chance of hack.
Soon, i’ll put this db on my site but if you are interested immediatly, sent a mail
RGDS to all admin, and even to developer
We have built our own notes app that creates both Notes and Active Directory users. This allows us to ensure that the AD username and shortname are the same. We have built a DSAPI for HTTP authentication to use AD username (= shortname) and password. Our world is R5.The app keeps a copy of the ID file and the original password – and logs all access on password retrieves.The Cert IDs are attached to profile docs in the DB, but only we level 3 administrators can see them. This allows staff in the remote office to create users but all our rules are embedded in the app so they can’t make mistakes.I have not seen either of the products you mention – but wouldn’t want cert IDs being outside my control.
I’m not familiar with OpenNTF’s own cross-cert system. Dovid Gross handled that. However, I do know that Dovid isn’t concerned with replicating that system across multiple servers, and probably set the Reader restrictions accordingly. He’s pretty skilled at this stuff. 🙂
Hi – thanks for those comments on iDM! I’m one of the three developers.
Okay – well, version six has this idea of a Certificate Authority – to prevent certifiers being used by non-authenticated folk. Nice. But it seems to rely on ACL level access – and our product – iDM – is based around the premise that the Admins themselves are the people you wish to protect yourselves from.
Our model is based on the one that we built five years ago for Philips (for IBM) – its pretty secure. Certificates, user ID’s and passwords are all in separate databases, with ACL access control set. And of course we *also* use notes encryption keys, forcing people to add anohter layer on top.
Once iDM is implemented on your site, the only people with access to the certifiers is the iDM process itself (and its pretty damn secure!) and your super-admins. You can even lock your directory down to reader acceess for everyone bar this group (and the admin-server).
We think we’ve got the most secure Certificate and password stuff in the business – thats what you get with 15 man-years experience in automatiing domino group and user management..
A few questions about iDM if you don’t mind:
— Can iDM sit on only one server in the domain and register users across multiple servers, or is a copy required on each server where users will be registered. That’s the current drawback of the ID Manager we use now from Helpsoft. http://www.helpsoft.com
— When you move a user in the hierarchy, can it only go one level (ie O to O) or can it do O to /OU/O?
— Can you choose to populate “non-standard” fields on the person document during registration. For example, the Location field. The reason for this is that we have agents that read the location field to build certain groups in the NAB.
Ok, I’m questioned out now! One day I’ll have some answers.
Request you to send me a copy of the evaluation report you made. I’m also currently on the process of evaluating the same.
Awaiting your reply