: 4400 | 106121 | 11884
|
: -3 : 1 : 4 |
In order to reduce the number of certifiers we have to manage, I would like to be able to use just the organizational certifier and use unique org unit to specify a geographic location at registration.
If a unique org unit could be set at registration with explicit policy, we could register everyone with the one organizational certifier and immensely reduce the work in managing our certificates. Being able to set the unique org unit will still allow us to create distinct organizational policies that we can apply based on the unique org units but only manage the one certifier.
|
1) Bill Malchisky8219 (26 Jan 2012)
Sounds like you are trying to bypass decades of security procedures inherent in the product. Are you using the CA process in Domino? That can simplify the registration process, if I understand you properly. Adjust your Registration policy settings document accordingly, for each region. Not sure how many regions are in your set, but bypassing OU level security is not the way to accomplish what you seek.
2) Matt Cook582 (29 Jan 2012)
Not attempting to bypass security. Simply want to reduce the number of certifiers we have to manage.
For our global organization, OU1 is a geographic site designation. We have organizational policies with registration settings, desktop settings, etc. per site.
What I would like to do is still register everyone, but at the O level, and set the unique org unit on registration via explicit policy. Currently we can do this but have to manually add the unique org unit at registration.
Hierarchically, the name is the same and organizational policies apply just as they would as if the person had been registered with a true /ou1/o certifier. ACLs with */ou1/o still work too.
This would mean that if someone changes geography, it is a simple user rename to change the unique org unit and doesn't require the extra steps of a certifier move.
It also means that if recovery authorities need to change, only one certifier needs to be updated. Also means that as CAs and RAs change, only one certifier needs to be touched.
In addition, if using ID Vault, only the O level certifier needs to be managed. In a scenario where password reset authority needs to be delegated to the service desk, as people come and go, only change needs to be made on that certifier instead of the numerous OU1 certifiers.
We would still create OU1 certifiers if needed and realize we would still have to manage the organizational policy and settings documents.
One situation I could see where this would be inflexible would be in a cross-certification scenario where you need to cross-certify at the OU level and couldn't.
How specifically would OU level security be bypassed in this configuration?
For our global organization, OU1 is a geographic site designation. We have organizational policies with registration settings, desktop settings, etc. per site.
What I would like to do is still register everyone, but at the O level, and set the unique org unit on registration via explicit policy. Currently we can do this but have to manually add the unique org unit at registration.
Hierarchically, the name is the same and organizational policies apply just as they would as if the person had been registered with a true /ou1/o certifier. ACLs with */ou1/o still work too.
This would mean that if someone changes geography, it is a simple user rename to change the unique org unit and doesn't require the extra steps of a certifier move.
It also means that if recovery authorities need to change, only one certifier needs to be updated. Also means that as CAs and RAs change, only one certifier needs to be touched.
In addition, if using ID Vault, only the O level certifier needs to be managed. In a scenario where password reset authority needs to be delegated to the service desk, as people come and go, only change needs to be made on that certifier instead of the numerous OU1 certifiers.
We would still create OU1 certifiers if needed and realize we would still have to manage the organizational policy and settings documents.
One situation I could see where this would be inflexible would be in a cross-certification scenario where you need to cross-certify at the OU level and couldn't.
How specifically would OU level security be bypassed in this configuration?
3) Mike Woolsey2784 (10 Feb 2012)
I think I get ya. The strategy is already available, there's just a particular method you want to be able to apply more readily.
There's no security being bypassed. The strategy continues to use the OU methods inherent in the product.
Don't we already have a "unique org unit" situation for two people with identical CN?
There's no security being bypassed. The strategy continues to use the OU methods inherent in the product.
Don't we already have a "unique org unit" situation for two people with identical CN?
Welcome to IdeaJam™
You can run IdeaJam™ in your company. It's easy to install, setup and customize. Your employees, partners and customers will immediately see results.
Use IdeaJam to:
- Collect ideas from employees
- Solicit feedback and suggestions from employees and customers
- Run innovation contests and competitions
- Validate concepts
- Use the power of "crowd-sourcing" to rank ideas and allow the best ideas to rise to the top
IdeaJam™ works with:
- IBM Connections
- IBM Lotus Quickr
- Blogs and Wikis
- Websphere Portal
- Microsoft Sharepoint
- and other applications.
IdeaJam has an extensive set of widgets and API's that allow you to extend and integrate IdeaJam™ with other applications.
Learn more about IdeaJam >>
IdeaJam developed by
