I was asked to disable a user from all Domino resources. That means Traveler, Mail, Applications & Sametime. All of the Domino servers have "Terminations" group listed in the Not Access Server field of the server document. I added that user's name to the group and replicated the Name & Address book to all of the servers thinking I was done.
The next day, the user logged into Sametime and was still using Traveler.
Sametime is set up to be used by embedded notes clients, through the web and through iNotes.
What step am I missing to prevent this user from using ANY Domino related services including sametime and traveler?
Hi @Quin Filipowicz Check these below articles
For Sametime:
> How to use an agent to populate the "Home Sametime Server" field.
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0081284
> How to secure a Sametime server to prevent unauthorized users from accessing the server
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0037112&sys_kb_id=2ed72cac1b6df30083cb86e9cd4bcb0d
For Traveler
You may restrict the user to access traveler using the server document access field in HCL Traveler tab in traveler server document. You may refer to the knowledge article below:
Title: Restricting access using server document access field
Link: https://help.hcltechsw.com/traveler/11.0.0/Restricting_access_to_server_using_Lotus_Traveler_settings_page.html
You may also choose to delete the user in HCL Traveler
Title: Deleting a user from HCL Traveler
Link: https://help.hcltechsw.com/traveler/11.0.0/Delete_user_from_Domno_Directory.html
Check the below setting too:
Go to the Server document > Ports > Internet Ports > Web > Enforce server access settings > Set it to Enabled.
The users in this termination group would receive a 403 error when they try to login on Webmail, Verse, or any other web applications.
Also, try to run updall against names.nsf using the command "load updall names.nsf -R" on the server console.
You have to be careful before enabling this setting because this will really lock out all users which are not allowed to access by Notes Client.
A simpler way could be to remove the Internet password from person document, so HTTP login will also be no more possible
I don't think it is enough to disable access to Sametime web or mobile: am I wrong?
Thank you for your thoughts. I'm going to try to have the Domino servers enforce the server access settings. If I don't want a person accessing something, this will stop all instances.
Does the server need a restart if I make this change?
I also like the idea of removing the Sametime server once replication is set up correctly. Internet password removal would be my last option because it's a real PITA to reset someone's password. Too many things rely on the internet password and if this is a temporary restriction for this user I want to make very little mods to get them back up and running if it's a false alarm. We don't synchronize our AD passwords with Domino, but we will soon. At that time, resetting the password would be the best choice.
Thanks for the warning Mathias.
For traveler, the server access settings (https://help.hcltechsw.com/traveler/12.0.0/Restricting_access_to_server_using_Lotus_Traveler_settings_page.html) are enforced by the HTTP process at auth time. So if you are using SSO, a device may be able to continue to access the server until the cookie times out. You can also block at the device level using the Traveler web admin interface: https://help.hcltechsw.com/traveler/12.0.0/Denying_or_allowing_access_to_a_user.html or the console using the tell traveler Security flagsAdd flag device user (where flag can be lock or wipeApps). If you really want to wipe the traveler data, then that necessarily means that the device must be able to get to traveler so it can tell the device to wipe (once the wipe action is set, that device will be blocked until the admin clears the wipe). So there's a bit of a chicken and egg issue if you block access at the front (ex: server access fields) then it may not get the wipe request.
Regards,
Curtis Ebbs
HCL Traveler Development
I ended up just denying the device. That should stop the user from using traveler, right? If they want that user back and working as if nothing happened, I can simply just re-approve the device.
If you are using device approval, which it looks like you are, then yes, you can just re-approve the device.