Domino on Linux/Unix, Troubleshooting, Best Practices, Tips and more ...

NSL, ID-Vault and Roaming working together

Daniel Nashed  30 March 2011 08: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

1Adam  30.03.2011 10:53:24  NSL, ID-Vault and Roaming working together

Do you have a reference about Single Logon being deprecated? I thought that Single Logon was going to work and be supported with ID Vault (after some known bugs were addressed).

Our current system for roaming and password sync works a lot more smoothly than the NSL/IDV described above, so I hope it's not going to be removed.

As a minimum, Shared Login doesn't work for us until there is some solution for synchronising the internet password as well.

2Lars Berntrop-Bos  30.03.2011 15:22:29  NSL, ID-Vault and Roaming working together

Single Logon doesn't work on 64-bit Windows. That deprecates it right there.

3Lars Berntrop-Bos  30.03.2011 15:25:35  NSL, ID-Vault and Roaming working together

Forgot to add: NSL does work on 64-bit Windows.

So I just Logon to Windows 7-x64, and start using Notes without it prompting me for a password.

Love it!

4Christian Henseler  30.03.2011 15:53:35  NSL, ID-Vault and Roaming working together

Starting with 8.5.2 FP2, Notes Single Logon is officially working on Windows 7 (client OS!) 64-Bit:

SPR# JZJZ7XA7FS (LO47208) - Notes Single Logon will not function on Windows 64 bit client OS due to an incompatability with the 32 bit Lotus Notes Client. With this fix, Notes Single Logon will function on 64 bit Windows client OS.

5Frank Hagen  30.03.2011 15:58:30  NSL, ID-Vault and Roaming working together

@2 With 8.5.2 FP2 SingleLogon should work on 64-bit Windows. Look here:

{ Link }

@Daniel: Did you try NSL and ID-Vault on Citrix?

6Daniel Nashed  30.03.2011 15:58:46  NSL, ID-Vault and Roaming working together

Some answers:

NSL is not working on Citrix and IBM is aware that we need a solution for Citrix and they are having ideas how to implement a solution but it will take a while.

ID-Vault works on Citrx and there is on-going work to support it starting hopefully with 8.5.3 -- there is also ongoing work to support XenApp 6.0.

The reference for the deprecation of Single Logon is directly from product management/development. I wasn't aware of this myself and that's one of the reasons I wrote this abstract.

For sure it will not work correctly with ID-Vault. Single Logon is a very basic and not very secure technique which basically supplies your password similar to a password handler you can write as an Extension Manager. ID-Vault works on a lower level. Same is true for NSL.

Even Single Logon is now working with Win64 as Christian and others state, it is not really supported any more from what I got as a feedback from IBM.

I will ask for an official statement and maybe we get a TN.

There is no sync for the HTTP password. The FAQ for NSL says that we should use SPNEGO or implement a DA that accesses an Active Directory (if you don't have a password on the person doc, the server uses the next available directory that has the same user and a password).

But you are right there is no password sync and also no way to change your ID-Vault password.

My main point for not using Single Logon is because of the missing support for ID-Vault.

And I agree that there is some missing functionality like the missing password change (for ID-Vault password and HTTP password) that needs to be addressed in some way.

-- Daniel

7Alin  30.03.2011 16:06:35  NSL password policy and iNotess password

NSL will stop iNotes password sync.

SPR SAKI7P88GT

8Andy Brunner  30.03.2011 20:26:07  NSL, ID-Vault and Roaming working together

Exzellent article! Thanks a lot.

9Craig Wiseman  31.03.2011 23:25:54  NSL, ID-Vault and Roaming working together

No HTTP sync kills it, dead in the water, for us. <sigh>

I really figured that the concepts of ID Vault, Roaming user, HTTP password sync, and Citrix use, etc. would all be blended to together and work pretty well by now.

10Adam  02.04.2011 15:51:31  NSL, ID-Vault and Roaming working together

@6 Absolutely. Single Logon isn't great, but it's possible to cobble together a usable solution. Without IDV and HTTP sync Shared Login isn't functional.

Also, not everyone has an AD domain. What are we supposed to do in that case?

BTW, I was told a while ago that they were working on supporting IDV with single logon. Sounds like that was probably abandoned in favour of just throwing the feature away.

11Adam  04.04.2011 13:34:17  NSL, ID-Vault and Roaming working together

@6 How exactly did you get this information? I just opened a PMR to ask about this and was told they don't know anything about it.

(I'm not doubting that you're correct, just interested in the magic words I need to talk to IBM support!)

12Daniel Nashed  04.04.2011 22:53:29  NSL, ID-Vault and Roaming working together

@Adam, I spoke with the product manager and he checked with the lead developer for Notes/Domino security to check for the supported configurations. I also send my feedback about what I think is need and they got a link to my posting afterwards.

13Daniel Nashed  05.04.2011 11:57:00  NSL, ID-Vault and Roaming working together

@Adam, but I am happy to share what I get back to give information back to the community :-)

14Adam  05.04.2011 12:04:48  NSL, ID-Vault and Roaming working together

Obviously you're slightly better connected than me :)

15Faisal  14.09.2011 17:28:19  NSL, ID-Vault and Roaming working together

Anyone know if NSL violates the FDA's 21 CFR Part 11 requirements?

16Reinhard  25.11.2014 12:45:06  NSL, ID-Vault and Roaming working together

Does anyone know if shared login now works correctly with ID-Vault? Don't find any actual information about this.

17Daniel Nashed  25.11.2014 12:52:47  NSL, ID-Vault and Roaming working together

Notes Shared Login (NSL) is designed to work with ID-Vault and should work.

18Reinhard  23.02.2015 12:46:08  NSL, ID-Vault and Roaming working together

Are there any updates on NSL + Citrix? In official help of ibm notes/domino 9 it is still "unsupported":

{ Link }

19Daniel Nashed  02.03.2015 11:50:10  NSL, ID-Vault and Roaming working together

NSL will never be supported in the way it is currently implemented.

The used Windows API cannot be used with a roaming profile. The data is encrypted in a way that is only working on the same machine.

For Citrix the official supported way is to use Federarted Login with SAML. But that's a bigger project .. not just a simple setting that you just deploy ..

-- Daniel

20Roland  13.10.2015 15:24:52  NSL, ID-Vault and Roaming working together

Whats about Notes Shared Login in conjunction with iPhone Traveler Access and Companion App?

21Daniel Nashed  14.10.2015 9:23:08  NSL, ID-Vault and Roaming working together

@Roland, NSL has nothing to do with Traveler. What exactly are you looking for?

22Roland  14.10.2015 12:41:57  NSL, ID-Vault and Roaming working together

NSL is eliminating the password of the Notes ID on the client. I thought that, if this password change is synchronizing to the ID-Vault, I won't be able to read an encypted mail on the iPhone with the Companion App.

It seems that the NSL modified ID is not synchronizing back to the ID Vault.

23Daniel Nashed  15.10.2015 13:25:22  NSL, ID-Vault and Roaming working together

@Roland, yes the NSL password is never synced back to the vault.

There is no normal password in the client any more!

That's why password changes are a bigger challenge when you use NSL!

24Dietmar  15.12.2016 17:34:05  NSL, ID-Vault and Roaming working together

Regarding http password going off-sync:

Anyone ever figured out to have (traveler-)domino to authenticate the user (through DA) against an AD-LDAP for the web protocols? Given the user at least knows its Windows password this at least could alleviate the http password sync issues caused by NSL; that is, could make the http password entirely obsolete.

Another way (but maybe 2nd choice) could be to one-way-sync the AD password into the Domino password (by back end job (e.g. using big iron TDI or something lighter solution).

25Daniel Nashed  15.12.2016 18:51:17  NSL, ID-Vault and Roaming working together

@Dietmar, yes using the AD password for HTTP authentication including Traveler works.

You have to configure LDAP AD as a trusted directory and remove the HTTP password from the person doc.

But you should be aware that this might lead to a lockout of your AD user if someone exeeds the login attempts.

-- Daniel


  • [IBM Lotus Domino]
  • [Domino on Linux]
  • [Nash!Com]
  • [Daniel Nashed]