NSL, ID-Vault and Roaming working together
Daniel Nashed 30 March 2011 06:34:57
For a customer project I had to look into details of NSL, ID-Vault and Roaming in combination.
The customer currently uses Roaming and Single-Logon. They are currently deploying and syncing their Notes.ID using a network drive and login/logoff scripts.
With Notes 8.5 the goal is to move to ID-Vault to replace this custom roaming.
Single Log-On not supported any more
When I started to test the functionality I noticed that Single-Logon is not supported with ID-Vault and does not work in combination.
It turned out that Single-Logon should have been removed from the product in 8.5 and is not fully supported any more.
The functionality has been replaced by Notes Shared Loging (NSL) which works in a completely different way and is fully supported with ID-Vault.
NSL is designed to work with ID-Vault from the beginning but brings in a couple of changes.
Differences between Single Log-On and Notes Shared Loging
In simple words without going to much into technical details, Single Log-on plugs into the authentication of windows, captures the password and stores it in a save, encrypted memory location.
When the Notes Client needs the password the password will be applied from memory. If the password is changed the Notes.ID password is changed as well. That way Single Log-On allows you to only type in your password once at login.
With Notes-Shared Login the Notes.ID password is automatically replaced by a very strong password which is stored encrypted in your local Windows profile and protected with your Windows accout password.
This binds your Notes.ID to your current machine and you cannot use this Notes.ID on different machines thru for example a file-server.
NSL is activated in the Notes Security Policy Settings and needs no extra software to be installed.
It will not work when the old Single Log-On Service is installed for security reasons.
Roaming and Shared Login
Both features work together as long the Notes.ID is not roamed using Notes Roaming. Instead the Notes.ID should be roamed using Notes ID-Vault.
In that case the newly downloaded Notes.ID is automatically protected with NSL.
ID-Vault and Roaming
Both features work nicely together. In fact when ID-Vault is enabled it is used instead of the standard Notes.ID roaming functionality (roaming the Notes.ID thru a profile in the Notes Personal Address Book).
So you have to exclude the Notes.ID from roaming and instead leverage ID-Vault.
This makes perfectly sense because the Notes.ID is better protected and managed in ID-Vault than when using roaming.
ID-Vault
In this roaming scenario ID-Vault is used to deploy Notes.IDs to new workstations you roam to.
When you access a new workstation for the first time the Notes.ID needs to be downloaded from the ID-Vault.
In this case a user has to type in his/her current Notes ID-Vault password and if the download of Notes.IDs is not set to automatic the download count needs to be increased.
After downloading the Notes.ID it will be automatically protected with NSL and there is no separate Notes.ID password on this workstation.
Current Limitations
This looks all great but there are currently some smaller limitations. The users ID-Vault Password never changes and if the user has to change his windows password for example every month the ID-Vault password is not changed automatically.
And there is also no out of the box way to have the user change their ID-Vault password on their own in this scenario.
In normal cases the ID-Vault password is synced when changing the Notes.ID password on a workstation -- along with all other parts of the Notes.ID.
But with NSL there is no Notes.ID password any more and there is no password change option any more.
There are two ways to work-around this limitation
a.) Have a plugin on AD-level and user the password reset API to change the passwort in ID-Vault without triggering that the user needs to change his password the next time he/she logs in.
Not all customers like to add "hooks" to their Active Directory and this might not solve all issues for a customer.
b.) Have a self service application which controls password changes of the Notes.ID Vault password for a user and also setting the download count for the Notes.ID.
Every time the user tries to increase the download count password change policies could be applied thru this application and even if the user did not use the password for a long time nobody could download a Notes.ID meanwhile when the download count is zero.
There is a Lotus Script call and also a C-API Call (shown below) that allow to set the password and the download count at the same time.
But if the password does not need a change the download count could be set without changing the password.
This is not completely documented but when I asked for this functionality thru an enhancement request IBM came back and said this is already implemented in the password reset API (see below).
This gives you already great control but you cannot decide at this level if the user needs to change the password at next login.
A security policy setting is used to specify if the user needs to change his password after it has been reset by and administrator or password reset application.
So if you want to use this functionality currently you have to disable this part of the security policy.
It would be great if we could disable it in the security policy and still set a flag when using the password reset to trigger that the user needs to change the password at next logon.
I have asked for an enhancement request for this functionality and got a SPR number
SPR #DKEN8EET7Z: Vault enhancements: APIs to increase download count and reset pwd w/o change
I really would like to see this option for SECidvResetUserPassword and also a way that the user can change his own ID-Vault password.
And if you have the same need you might want to open a PMR to give this SPR a higher priority.
Conclusion
There are ways to bring this three technologies together. In combination with the download count it can make sense that the Notes.ID Vault password is not changed automatically.
A password change/reset/download count increase application can help to improve security and can fit into current infrastructures.
In our case we will use the central application to allow roaming to a new workstation. This way we have also closer control of the Notes.IDs and also which workstations a user roams to.
I hope this gave you some ideas for your own environment. So even without roaming most other parts of this blog post are still relevant when using NSL and ID-Vault in combination.
-- Daniel
Reference from C-API
STATUS LNPUBLICFUNC SECidvResetUserPassword(
char *pServer,
char *pUserName,
char *pPassword,
WORD wDownloadCount,
DWORD ReservedFlags,
void *pReserved);
- Comments [25]
![[HCL Domino]](../lotus-domino.gif){kind=small}
![[Domino on Linux]](../domino-linux.gif){kind=small}
![[Nash!Com]](../nashcom.gif){kind=small}
![[Daniel Nashed]](../daniel-nsh.gif){kind=small}