Understanding HPE/MicroFocus Data Protector's user authentication (Windows GUI)

U. Windl

1/27/24, 10:15 AM

Following the manual to install a new Cell Manager (CM) for Micro Focus Data Protector 11.02, I got stuck at the point when configuration should start using the Windows GUI:

First The PC being used to connect to a different CM had problems connecting to the new CM (even though the other CM had also version 11.02). The first issue was that the old installation used port 5555 to communicate, while new installations use port 5565. Interestingly when connecting to a CM you cannot specify a port in the GUI (at least not that I found out: Using host:port definitely does not work) The issue was related to certificates, and even if the client had stored a different certificate for the new CM, it seemed to present the certificate of the other CM, causing a connection failure. After significant work I was able to connect to the new CM, but lost connection to the old CM (but that's a different story)...
Once I had a connection to the CM, I could not log in. The installation manual is very silent about this, so I created a user the same way as in the old CM (I'm using the same PC to connect). But first the new installation did not allow * for the "group", and second I could not log in (In the old installation I was never asked about user or password; I assume the Windows Active Directory credentials were accepted somehow). After spending half a day with reading docs, trying different things (like creating and testing multiple variants of user entries), and eventually browsing all logs on the CM, I entered the user as displayed as "Web Username" on the output of /opt/omni/bin/omniusers -list. And that worked!

So I wonder:

Is it expected that the user has to enter the username like "user_id|group|client"? If not, what might be the problem in the user created on the CM (I created the user using Windows user's loginname as "name", Active Directories name as "group", and the fully-qualified hostname as "client")?

221

2 + 0

active-directory

authentication

data-protector

Score:0

Server

U. Windl

2/7/24, 12:16 PM

I found the "solution" using debugging:

In the GUICORE debug log on the Windows client I saw that cmnHostname and cmnNodename were different from the FQHN that nslookup would report on client and CM; it seems the client name the GUI uses comes from Active Directory, not from DNS (Domain name Server/Service)!

After changing the user's client to the name found in the debug log, authentication worked as before.

An alternative would have been to enable the */ANY client matching by setting EnableAnyOptionUserCtx=1 in /etc/opt/omni/server/options/global and use * for the client hostname.

+ 0

Score:0

Server

SertVert32

1/31/24, 7:25 AM

to access data protector gui you you need to use following format https://DP_Server:7116/web loginname can be found in the Cell Managers Users Web Credentials for example admin|/'*|DP_Server to be able to connect to GUI from other hosts export CA certificate from cell manager open https://DP_Server:7116/web and open certificates . Export CA Certificate and install it to trusted store

+ 2

U. Windl

2/6/24, 2:06 PM

First the URL given does not work here: I get only something like eight random Unicode characters. Despite of that I made an experiment: I created a user with group `x` and client system `y`. I could log in from any client just specifying `testuser|x|y`. I still believe the GUI should build the user string (add group and client host) from the username, not the end-user. It does not add any security if the user can specify group and client, because it's basically just a username that works from any host. My question is not related to any certificate as far as I can see.

U. Windl

2/6/24, 2:06 PM

Also point out in your answer where a new sentence begins (use capital letters and a full-stop, please).

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Understanding HPE/MicroFocus Data Protector's user authentication (Windows GUI)

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.