A New Way to Manage Notes User IDs and Passwords
September 19 2008
Let's talk about the creation and storage of Notes ID files for a moment.
When you create a Notes ID for an end user, where do you put it? Do you keep a copy of it somewhere so that you have access to it in the future? What about the password? Do you use a generic password so that if a user forgets it you have a copy with a known password to give them? And when a user requires that original copy (because of a lost password or such) how do you deal with any changes that occurred from the time the id was created until the time they requested a new one? Things like name changes, certificate changes, encryption keys, etc? And what about users with multiple versions of the ID file - on shared computers or such?
A lot of questions, I know. But these are also questions I get asked all the time by my customers wondering how to handle things like this.
Over time, many customers have dealt with this issue in many ways - from using a file server to implementing a complex and expensive 3rd party tool to manage Notes IDs. Unfortunately, you usually have to compromise one thing for another - security vs. usability. It's easy to place the ID file on a file server or in a Notes database and use generic passwords - but it's not very secure. Or, some of the 3rd party tools make it very secure, but they aren't particularly easy to use or manage. We're often left with a solution that is cumbersome and/or expensive to manage.
It's pretty much been the only thing you can do to manage those id files and provide some level of password or id file recovery for your end users. Is it easy? NO. Is it secure? Not usually. Is it a pain in the administrative you-know-what? YES! This has led many of you to ask "Why can't we just get rid of the id file?" But then, you stop and think about the security infrastructure the id file gives you and you wonder - "Well, maybe there's a better way." THERE IS!
Domino Administrators Rejoice!
There's a new feature in Domino 8.5 that will help to ease your Notes ID file woes. It's called the Notes ID vault. The Notes ID vault is meant to help you manage and maintain Notes ID files without compromising the security of the ID file itself. Imagine if you will, a world where:
Shouldn't you be able to manage those ID files without compromising the security of them? Shouldn't end-users be able to recover their password on their own - maybe without even having Notes Administrator intervention? And what about during those messy litigation efforts when you need access to someone's encrypted mail file without knowing their password..shouldn't you be able to do that easily too? Anyone who's been a Domino Administrator has got to be saying "Yes, Yes, Yes and YES!"
That, and much more is what Notes ID vault provides. Essentially, Notes ID vault is implemented with your certification hierarchy and policies. When you register a new user ID (you can even get all your existing IDs, so don't worry), you have a new option to place the ID file in the vault. Then, using the Domino Administrator client, you can configure the vault settings like password recovery, setup vault auditors, configure vault security or extract the ID from the vault when needed. And, once everything is configured, end-users can now access the recovery configured in the vault and get it back themselves. Then, through the beauty of policies, those multiple copies of ID files, etc. is synchronized and very nicely managed. How much cooler can you get??!!
So there you have it, folks! I think ID vault is going to make life a lot easier for many people! Watch this space for upcoming posts on more details like security and implementation. And..I'm hoping to get a nice case study for you from IBM's own implementation of ID vault! Stay tuned!
When you create a Notes ID for an end user, where do you put it? Do you keep a copy of it somewhere so that you have access to it in the future? What about the password? Do you use a generic password so that if a user forgets it you have a copy with a known password to give them? And when a user requires that original copy (because of a lost password or such) how do you deal with any changes that occurred from the time the id was created until the time they requested a new one? Things like name changes, certificate changes, encryption keys, etc? And what about users with multiple versions of the ID file - on shared computers or such?
A lot of questions, I know. But these are also questions I get asked all the time by my customers wondering how to handle things like this.
Over time, many customers have dealt with this issue in many ways - from using a file server to implementing a complex and expensive 3rd party tool to manage Notes IDs. Unfortunately, you usually have to compromise one thing for another - security vs. usability. It's easy to place the ID file on a file server or in a Notes database and use generic passwords - but it's not very secure. Or, some of the 3rd party tools make it very secure, but they aren't particularly easy to use or manage. We're often left with a solution that is cumbersome and/or expensive to manage.
It's pretty much been the only thing you can do to manage those id files and provide some level of password or id file recovery for your end users. Is it easy? NO. Is it secure? Not usually. Is it a pain in the administrative you-know-what? YES! This has led many of you to ask "Why can't we just get rid of the id file?" But then, you stop and think about the security infrastructure the id file gives you and you wonder - "Well, maybe there's a better way." THERE IS!
Domino Administrators Rejoice!
There's a new feature in Domino 8.5 that will help to ease your Notes ID file woes. It's called the Notes ID vault. The Notes ID vault is meant to help you manage and maintain Notes ID files without compromising the security of the ID file itself. Imagine if you will, a world where:
- During registration, the Notes ID file is automatically stored in a secure database
- End users can recover their password on their own
- Multiple copies of the Notes ID file are automatically synchronized
- Specified auditors have access to encrypted data for litigation and other purposes
Shouldn't you be able to manage those ID files without compromising the security of them? Shouldn't end-users be able to recover their password on their own - maybe without even having Notes Administrator intervention? And what about during those messy litigation efforts when you need access to someone's encrypted mail file without knowing their password..shouldn't you be able to do that easily too? Anyone who's been a Domino Administrator has got to be saying "Yes, Yes, Yes and YES!"
That, and much more is what Notes ID vault provides. Essentially, Notes ID vault is implemented with your certification hierarchy and policies. When you register a new user ID (you can even get all your existing IDs, so don't worry), you have a new option to place the ID file in the vault. Then, using the Domino Administrator client, you can configure the vault settings like password recovery, setup vault auditors, configure vault security or extract the ID from the vault when needed. And, once everything is configured, end-users can now access the recovery configured in the vault and get it back themselves. Then, through the beauty of policies, those multiple copies of ID files, etc. is synchronized and very nicely managed. How much cooler can you get??!!
So there you have it, folks! I think ID vault is going to make life a lot easier for many people! Watch this space for upcoming posts on more details like security and implementation. And..I'm hoping to get a nice case study for you from IBM's own implementation of ID vault! Stay tuned!
1) Keith Strickland wrote: (email)
I actually developed an opensource solution to this problem for versions before 8.0 called the User Administration Utility which is hosted over on OpenNTF that took care of a lot of that. Users could via a website:
* Request their original id file be sent to them via email
* Request a new ID file be created if they didn't already have an ID file
* Request a rename and it would rename the person but an administrator would have to go in and switch to the ID and accept the name change
* Request recertification if their certifier had expired
This was all done via a web site and all password protected and access was controlled via reader/author fields. The password of the original ID file was stored so that an administration team had access to it and then the only other person that has access is the user and only via the web. There was also various amounts of information stored within a "person" document including the groups they are a member of and other notes specific information. It was a very handy utility, but with version 8.0 it broke the ID creation part of the app. But it's nice to see that IBM finally addressed this issue as it's been a sore topic to say the least.