Showing posts with label TOTP. Show all posts
Showing posts with label TOTP. Show all posts

Tuesday, August 20, 2024

SnTT - Does TOTP Work for users in a Secondary Directory via DA

TOTP, DA, and Domino

For the last 3 years, I have worked with TOTP inside HCL Domino and customers with unique requirements.

This has provided fodder for my blog, and today, we have a new entry into the TOTP Mystical Ways of the World.

Let me state my usual caveat upfront: TOTP is about the URL, not the server, the database, or the user.

You enable TOTP for each URL you want on your server.

PSA is completed. Let's discuss the circumstances that brought me here.

Like many of our customers, a customer has a large external user community relying on their applications.

The customer has licensed this with HCL, so I am not going to get involved in that discussion. However, be warned: It is not a comfortable one if you have been relying on some old licensing options and now fall under the new ones.

We have about 7,000 external customers. Some are undoubtedly old customers, but 7,000 is a lot of people.

Previously, I wrote about how to bulk add these people into your ID Vault, and that was all fine and good where we have only one names.nsf for everyone and everything. We may have had 2-3 servers in that org.

Now, the 7,000 are in a secondary external names.nsf via DA (Directory Assistance).

The Problem

1) How do you register and maintain the people in a secondary Directory?

2) Does the DA even work with TOTP? 

The Options I See

Officially, there is only one place, and one place only, where everyone gets registered: the names.nsf.

This is not very helpful, especially given the reliance on the ID Vault for many things these days. By changing licenses, there is no way to "convert non-ID people to Notes ID people."

What do you do?

1) Copy, not replicate, the name.nsf, to extnames.nsf, move the actual names.nsf out of the way, rename extnames to names and then register everyone to it. Once done, put back the original names.nsf and off you go.

As pointed out in our Openntf.org Discord channel, the problem with this is that the user and ID would not be properly found for encryption/certification. This is a very valid point I wasn't thinking about at first. Thank you, Ulrich and Detlev.

2) register all 7,000 into the names.nsf properly, like normal. Then, manually copy the 7,000 to the extnames.nsf. Then delete, just regular delete, not Adminp delete, the 7,000 from the names.nsf.

By doing this, we preserve the user's encryption/certification, and should a name need to be renamed/edited, we can copy the user back and fix it. One could also just create a new account etc.. and remove the bad one from extnames.nsf.

3) Create a new Domain and register everyone to it and cross certify it with the existing domain. This may or may not be the answer as well, depends on circumstances.
4) I have no other idea otherwise. However, there is an AHA idea asking HCL to think about a way to register people to some other .nsf. Take a look and vote over here

If anyone has any ideas, let me know in the comments.

I will get to the DA question shortly.

Details and Planning

I started with my blog post and the CSV file I needed with 4 test users.

Copied the 4 test users from the extnames.nsf to the names.nsf.

Went to register the users, verified information etc..

And got this error: "The user's flat name matches another user with a different hierarchical name."

You should know that I ran into a bug in the Notes Admin and Domino Server v12.0.2, which you can read about here. Upgrading the client/server is the basic answer to resolve this one. Since Domino was already at 14.0FP1, my Notes Admin client had yet to be updated. 

Once updated, everything went as it should.

Well, only some things. 

I need to do more testing, but I think the "just updating an existing user" registration option is not working properly because I now have 2 completely different entries for each test user. 

My theory is the existing users being "unregistered web users" with "other mail" were not seen as the same people, and so Domino created the new entries. I know the ways to work around this if it is the case, but more testing will validate what I need to do. After all i will have 7,000 to update, fixing one manually is fine, but all of them? For that, I have my Openntf Admin Snippets to help me. I will blog about this after testing is completed.

In any event, I copied the 4 people out of names.nsf, put them in the extnames.nsf, and reindexed both directories as it was testing time.

Testing TOTP and DA

Ready for testing, I turned on TOTP in the Security setting, edited the domcfg.nsf for the test URL, and checked that the extnames.nsf was enabled in the DA, then restarted Domino.
When Dominno comes up, everything looks okay. I open a browser, put in the URL, and see the login screen with the MFA details. So far, so good.
The first test is my own log-in. I am in the names.nsf, and my ID is in the ID Vault. I passed, and there are no issues.
Log in as one of the new test users for the second test. Invalid password.
It seems, and this may be a customer agent, that the users are not supposed to have a web password. I added there password back, it was in my CSV, and reindexed and tried again.
Different error. User not found type error.
I was logging in as FirstName LastName, which is how I logged in, but there is only one record of me, but 2 of the test users. I logged in with the Org domain name and got one step closer, this time it just crashed on me.
Ok, I cleared the browser cache, restarted Chrome, and tried again.
This time I received a invalid access error.
This is important because the HCL documentation does not say anywhere that the DA will work with TOTP on its own. It only discusses the DA via Cross-Domain Authentication, as you can see here.
I looked at how the DA was set up and changed the Group Authorization setting to Yes from No.

Made sure Trusted for Credentials in the Naming Contexts tab was set to YES.
Then I tried it again.
And it worked this time. I was prompted to set up the MFA and log in as the extnames test user.

Conclusion

I still have more procedures to test and document, but the ability to leverage TOTP in a secondary directory via DA is not a limitation for the rollout. 


Thursday, October 27, 2022

How to Enable, or Disable, TOTP for HCL Traveler and Verse

 After a discussion with fellow HCL Ambassador David Hablewitz, I realized I did not fully explain the HCL Traveler/Verse (will just refer to it as Verse) and TOTP  issue in my blog post the other day, 

I intended to explain the pros and cons of using TOTP and Verse, but I neglected to explain how to enable or disable TOTP and what you do if you have one server or separate servers.

The how-to is what this post is about.

It is pretty easy to do in a proper environment where Verse sits on its own server.

You probably see something similar to this in your Internet Sites for the Verse server (ignore the 404 error page I was testing):


If you double-click on the head item on the Web Site, you will see where you turn TOTP on or off. I am presuming you have set TOTP up already. The option is there because of the names.ntf template changes in R12 and R12.0.1.


If you don't want TOTP, change the selected option to "Yes" instead of "Yes with TOTP."

Simple, right? 

What if you are a smaller organization that relies on one Domino server to do anything and everything? What if you don't want Verse to have TOTP, but access to applications, or mail, should have TOTP?

My suggestion from a security perspective is to create a new URL for Verse. It is easier, under R12, for you to create a unique URL for your domain and get a Let's Encrypt SSL certificate for it for free.

Sidenote: I understand that you could leave it set up as it is above and turn TOTP off for the default website. You may do this because you don't want to field tons of help desk calls from users who can't change a URL, but this route would leave your whole server in a less secure mode.

Decide on the new URL, traveler.company.com.Set it up in your internal and outside DNS.

Create the new Internet Site document for the unique domain. It may look something like this:







Don't forget to edit your Traveler URL section of the server document to accommodate this change.

And now you can restart HTTP and Traveler, and you should get prompted for TOTP at your domain, but not with Verse once outside DNS changes go into effect. So I suggest you set it up and wait till the exterior works, then cutover internally.

You will need to create all the docs, so it looks like this:


And users may have to reinstall Verse to change the URL.

Once set up, you can turn on TOTP for Verse down the road if you wish. This also lets you move the Verse server easier in the future because it is no longer tied to your server, just the URL.

Tuesday, October 25, 2022

Customizing the TOTP Login Form and MFA Pages

Continuing the extension of my TOTP session from Collabpshere, I wanted to expand upon modifying the Login Form and MFA page for those who need it and want to know how to do it.

The truth is I covered this in my 2021 Collabsphere presentation but since learned a few things which I want to pass on to all of you.

In 2021, I created this flowchart explaining how to add your corporate logo to the background logo.

Editing TOTP Background with your logo
How to add your company logo to the TOTP Backgroud graphic.

Of course, you could use any graphic, just figure out the scaling side, but I found it easier to just add my logo to the existing MFASetup1.png file.

There is a style.css file (Under Resources-Style Sheets) where if you find this section, you can change the graphic to whatever you want by renaming the png file and, of course, adding your graphic to the Resources-Images section: 

Today I found it was not letting me add a company logo to the .png with the 12.0.1 template. I had previously done it with the 12.0 template. So YMMV.

So how do we let people know it is the company's MFA login page?

I edited the form called $$LoginUserFormMFA in the domcfg5.ntf. If you don't do it in the ntf, you will lose your updates when the design task runs.

I replaced the HCL Domino text with the company name and added MFA Login Page.

While editing the text, I added the details below, which is helpful since the default page tells the user nothing.

MFA Instructions / Help

To set up and start using MFA take the following steps:

Step 1: Enter your Username and Password and press the 'Login' button.

Step 2: Follow the prompts to set up Multiple Factor Authentication, our preferred authenticator app is Duo.

Step 3: Once you have set up the MFA, return to the login page. Enter in your username, password, and MFA Token via your authenticator

Step 4: Click the Login button.


Naturally, you can add whatever text you wish and probably add a popup help window, among other things, but I am just a simple admin.

 Don't forget to save your changes.

While still in this form, if you go to the list of objects below the window and look for the "Window Title" object, you can edit the text there, as I have, so it says "The CompanyName MFA Login Page." And don't forget to save your changes.

I like to minimize helpdesk calls, so I want people to realize it is a legitimate site. I know, hokey, but something is better than nothing.

The hard part, and I don't suggest you do this unless you really want to do it, is to edit the MFA Setup page.

You see, it is not a page, or a form, or a view. It is a small java file.

You would have to unarc/zip it or whatever you do to java files, edit it, recompile it, and put it back on your server.

And if you do a server update, it will wipe it out.

And you would have to do it all over again. You might be able to copy the file, but if HCL makes any changes, you are screwed, so I have decided not to mess with it.

The .ntf would also get overwritten on an update, so why do it there?

To me, it is easier to replicate and maintain a local copy of the .ntf than to do it for the java part, but again, YMMV.

My personal server page looks like this now:


If you previously had a custom login form and now want to add TOTP, I strongly suggest you copy your custom form into the $$LoginUserFormMFA and sort it out from there. 

There are too many parts to TOTP and the domcfg database that will make it hard to do it in reverse,

I am sure my developer friends may make fun of me, but this was the easier(less time involved) of the 2 ways we tried to do it to bring it up and make it work. Again YMMV.

I did not touch on the use of the notes redirector, but that is how we are using it, and of course, if you need to edit the iNotes Redirector, I wrote a few posts about it many years ago, you can click on that section from the top of my blog or use this link: https://blog.vanessabrooks.com/p/inotes-redirector.html.




Friday, October 21, 2022

To TOTP, or NOT To TOTP, Traveler/Verse users, THAT is THE Question

 

Whether 'tis nobler in the mind (of users) to suffer The slings and arrows of outrageous fortune security guidelines, Or to take arms against a sea of (illogical) troubles, And, by opposing, end their tyranny upon us?

Shakespeare will have to live with my edits.

Enjoy the video because it is THE definitive way to say the quote :-)

Now that Collabpshere has finished, it was a great event once again managed by Richard Moy with a supporting cast of dozens of people, I had a follow-up item from my session.

I will post the slides once I find a new home now that Slideshare has gone paywall.

The question continues to arise about using TOTP for Verse(Traveler) users.

If you attended my session, you heard me discuss the pro (not sure if there is anything beyond my insurance/compliance or security people require it) and the many cons. 

If anyone has more PRO reasons, let me know, but for now, this is the slide I used.


Remember that current phones usually require a code, slide design, finger, face, or eye scan just to let you into your phone.

Then the Verse app has a login and password for itself.

Do you still need an MFA after 2 levels? 

Also, if the whole purpose of the MFA is to secure the mail application, what purpose does it serve by being on your phone, if your phone is lost or stolen? Let's say the robber has the initial code(stop using your birthday or kid's birthday or anniversary). Then having the fa there is totally useless. 

So, why do you want to enforce this?

Right, because your insurance company told you.

Oddly enough, they did not tell you to disable SSO(Single Sign On), which negates any aspect of MFA a computer might have to start with. Nor do they expect you to have an MDM solution, which is really what you need for this purpose. 

Traveler/Verse has some aspects of MDM, like remote wipe, but does not verify your device has the appropriate number of digits in your passcode.

So, again, why do you need to do this?

Have you asked for the technical guidance document from your insurance company?

You should let me know if any of them ever produce one. And if they have one, does it make any sense?

TOTP is URL-based, not Server or Domain-based.

You can let Verse users use the usual traveler.company.com URL without TOTP while maintaining TOTP enabled for webmail.company.com see my slide below.



Yes, you can change the TOTP time-out setting (https://help.hcltechsw.com/traveler/12.0.0/auth_timeout_totp.html), which I did on my personal server, so I only log in with TOTP if my phone has been off for more than 18 hours. This happens every weekend, I shut it off an hour before sunset and turn it back on after sunset on Saturday.

The choice is yours, as the Admin, but you will have more help desk tickets every Monday morning and possibly every time a user flies, and they will think they are locked out.

So, in the immortal words of the Bard of Avon,

 "Out of this nettle - danger - we pluck this flower - safety."

'Henry IV, Part 1' (1597) act 2, sc. 3, l. [11]


Wednesday, October 20, 2021

My Collabsphere Session on TOTP/MFA and HCL Domino R12

Great to be speaking again at Collabsphere. 

This was the first of my 2 sessions, feel free to download it and ask any questions about it.

Tuesday, October 19, 2021

SnTT - TOTP Needs an ID file in the ID Vault to Work, What if some are Missing?


Yes, of course, a properly managed Domino environment should have been using the ID Vault for several years now.

But we all have customers who, for one reason or another, just never did it, or worse, think they did but never check that it worked.

And then we hear from them out of the blue to help get TOTP installed and update their environment.

No big deal, right? Set up the ID Vault, and when people log in to their Notes client, their ID files get sent to the ID Vault. Newly registered people are also automatically added to the ID Vault.

But what do you do about people who solely use webmail/iNotes?

How do you get their IDs into the ID Vault?

This, I thought, would be an easy thing, but it turned out to be way more effort than first thought.

One option is to select the user in the Directory with the names.nsf open, right-click on their person document, and select upload ID to the ID Vault. A similar Action from the top menu bar option can be found in the Admin client when the Directory is not open.

Not so fast. 

First, the option and action did not appear. Second, even if they did appear, we had 2 problems: where were these people's ID files and the better issue was who had the passwords? 

When you upload ID files to the ID Vault, Domino asks for the password for the file being uploaded, and if it does not match, you are out of luck.

We could not resolve the 2nd problem. More on that in a minute.

The first problem, I reached out to HCL Support to find out what happened to the action/agents.

Turns out they were in the template but not in the database.

After reviewing it with HCL, we found the customer had edited the People view of the Directory and set it to not update with changes from future templates.

I changed that setting in Designer and the properties of the view, then ran a replace design on the Directory, restarted the server, and it now worked and showed the action/agent items.

Now, back to the ID problem.

How can one register new users optimally without wiping out all their details in their existing person document?

I figured I needed to look at registering people with a text file and how to do it without changing their existing internet password or wiping out their mail file.

11 years ago, I wrote this post, https://blog.vanessabrooks.com/2010/06/id-registration-via-text-file.html, waiting for the moment it would be helpful again.

Well, that day has come. However, to be fair, I have used it a few times over the years.

I also searched for how to create a user but not a mail file. I did not get an answer to this in my searches or when asking some people, so I decided I just had to work around the issue. If anyone knows, please let me know in the comments, and I will edit this post accordingly.

Using the spreadsheet I created in 2010, I started figuring out what the syntax should be to complete this.

After a few tests, ok, maybe a few more tests, I realized I needed to maintain the file names but change the file directory. That way, dummy mail files would be created, which could be deleted, saving their existing mail files. However, the person document would now show the wrong location for the person's mail. Hang on, we will fix that soon too.

These people needed ID files in the ID Vault but would never use them otherwise. The ID files require a password, but we do not want it to synch with their internet password because that would overwrite their existing one. Domino has a way to help us do this, too; the explanation is below.

What does this spreadsheet look like before you copy the text to a .txt file? I figured I only needed to use a few fields, and this is what I used just 6 fields:

LAST    FIRST    PASSWORD    FILE DIRECTORY    FILENAME    EMAIL

Now the fun part is you need a semi-colon (;) after any entry you want to enter, so my text file for registration ended up looking like 250 of these(see the 11-year-old blog post for details on what goes in what order if you need more fields):

Brooks;Keith;;;PASSWORD;;;;mail2;kbrooks.nsf;;;;;;keith@b2bwhisperer.com;

But you need one more essential thing before starting the registration process for everyone.

If you click on options from the Registration window menu, 
you will want to check the line that says "Allow Registration of previously registered people," and check the "Don't prompt for a duplicate person" option, and select the most important option, "Update the existing address book entry.



When you use these settings, Domino will not stop for every duplicate user and just change precisely what we tell it to change in the person document.

In the registration form, you should ensure your ID Vault policy is set up for everyone.

As discussed earlier, we don't want to overwrite any existing Internet passwords; thus, you need to click on Password Options and uncheck "Set Internet Password"; otherwise, you will write over their current Internet password. HINT: Back up your Names.nsf before doing this, so if you do screw it up, you can get it all back quickly.

In the Mail tab of registration, you set the mail template to use and leave the mail file name field with just the directory name. The .txt file handles this.

Set the expiration date you want to use for everyone you are creating on the ID Info tab.

Now you import your .txt file, and Domino will tell you if any of them have syntax issues.

Domino will then let you know if anyone had issues or how many were completed when you ran it.

Please test with 2-3 people first, making sure all fields and entries look right, and the mail file is created where you specified.

How do we change the mail file locations, which now were mail2 instead of mail for 250 people out of 500?

A few months back, I started adding scripts to Openntf.org under the snippets Admin Scripts area to help other admins and for just this purpose. 

I took one of the scripts, adapted it for the Mail File location field, and then selected the users to run it on, and in seconds they were all back to normal. 

I posted that new script as well in case anyone will need to do this at the openntf site here.

Afterward, we had a few issues:

  • Some people we were told were solely web users were not. This meant they lost their ID certificate and could not log in. Easy enough to fix by copying the new certificate into their person document and replacing the old one. 
  • A few people in our spreadsheet had mistyped an email or mail file name and a few similar names and file names that got by us in editing. Easily fixed, we had a backup to verify what they should have in their fields.

And there you have it. I know it sounds like a lot, but really, it is not that big of a deal.