cancel
Showing results for 
Search instead for 
Did you mean: 

Running ha* CLI commands under secure server / single sign on fails

Ryan_Craig
Level 3

System description:

A Windows 2008 R2 SP1 VCS 6.0.1 cluster of two nodes.

Configured with secure / single sign-on

 

Problem:

Attempts to run any of the ha* commands (i.e. hagrp, hares, etc) from the command line as a non-administrator user fail with the following error message:

C:\Users\informix>hagrp -list

VCS ERROR V-16-1-53022 Broker (localhost) unable to authenticate user ((null)) : error = (14)

 
Details:
In this case I am logged into the system as an AD domain user named "testuser" in an AD domain I'll call "foo".  I can run the VCS Cluster manager as this user, and as expected can see the status of the cluster but not modify it (as I haven't granted any additional VCS privileges to this user), so it would appear that the secured VCS server is operating under single sign-on as expected.  Oh, just tried one more thing, added "testuser@foo" as an "Administrator", and now when I start the VCS Cluster Manager as user "testuser" it shows "TESTUSER@FOO" as a "Cluster Administrator" at the top of the Window, which would seem to confirm that SSO and authentication are working correctly, at least for the GUI.
 
I can log on as a domain or local Administrator (i.e. username <hostname>\Administrator or <AD domain name>\Administrator and run ha* commands from the command line.
 
One possible hitch may be that while the AD domain is (for example) "foo", the DNS/NIS domain of the AD domain and the VCS server is (for example) "abc.xyz.com"?
 
The following VCS services/processes are running on the host in question:
VCSAgDriver.exe
vcsauthserver.exe  <-- this is the one that handles authentication, right?
vcscomm.exe
VxSchedService.exe
vxsvc.exe
VxVDS.exe
vxvdsdyn.exe
 
The error message may provide some clue as to what the problem is, in that it identifies the user that it can't authenticate as ((null)), rather than "informix".
 
I've tried searching all over and I've got no clue as to why this doesn't work.  As an alternative I tried switching to the non-secure mode, but that resulted in the user "informix" being prompted to enter a username and password every time one tries to run a VCS ha* command.  For my purposes that is not usable, as our product (EMC NetWorker client) needs to run a script which in turn runs various ha* commands to determine the status of the cluster, which service groups own which disks, etc.  In theory using SSO should resolve this issue, but it's not working for CLI VCS commands.
8 REPLIES 8

Marianne
Moderator
Moderator
Partner    VIP    Accredited Certified

I cannot find the Windows equivalent in the VCS Admin Guide for Windows, but VCS commands on Windows are generally the same as Unix/Linux.

Try this method documented in the VCS Admin Guide for Linux:

 

To log on to a cluster running in secure mode
1 Set the following environment variables:
■ VCS_DOMAIN—Name of the Security domain to which the user belongs.
■ VCS_DOMAINTYPE—Type of VxSS domain: unixpwd, nt, ldap, nis, nisplus, or vx.
2 Define the node on which the VCS commands will be run. Set the VCS_HOST
environment variable to the name of the node. To run commands in a remote
cluster, you set the variable to the virtual IP address that was configured in
the ClusterService group.
3 Log on to VCS:
# halogin vcsusername password

mikebounds
Level 6
Partner Accredited

Marianne is right, halogin information is not in the Windows VCS Admin guide for 6.0 or 5.1, but it works for 5.1 on Windows, because I have used it.  Note authentication changed to "Embedded" in 6.0 so it works differently from 5.1, but as the UNIX 6.0 halogin commands in Admin guide are the same as 5.1, I assume the commands Marianne listed should work in Windows 6.0.  A few additional comments

The VCS_DOMAINTYPE should be set to "nt" as this means "AD domain"

If VCS_DOMAIN shows as abc for user logged in on GUI, then you should use this in command line rather than abc.xyz.com

Giving password as an argument to halogin is optional, you can just use "halogin user" and then it will prompt for password which as in a normal login, can't be seen as you type it.  If you are using a script then you can specify password in script by using "halogin vcsusername password", but this is not very secure to have a plain text password in a script, so what worked in 5.1 for UNIX was:
As a one-off, use "halogin user" manually as the user the script will run as and this should create a hidden .vcspwd file containing an encrptyed password and this file remains there until you run "halogin -endsession host" or "halogin -endallsessions", so if you DON'T run this, then you should be able to subsequently run commands WITHOUT having to use halogin, even if you log out and log back in again.

In 5.1, you could use command vssat to give you information about authentication - if this is still available in 6.0, you can try the following to give useful info:

vssat showallbrokerdomains
vssat showcred

Mike

Ryan_Craig
Level 3

Thanks for the replies.

Editted my post a little for clarity about the domain names - AD domain is, for example "foo", while NIS/DNS domain is "abc.xyz.com" - no commonality between them.  The domain that shows up in the VCS GUI for user "testuser" is "FOO" - the AD domain name.

I've searched, and as near as I can tell there is no such thing as "halogin" in VCS 6.0.1 for Windows.  But, under single sign-on / secure server mode, there should be no need for it, as VCS is supposed to use the OS authentication methods, or to be more precise, accept that user authenticated by the OS mechanisms do not need further authentication.  

I have used halogin on Unix VCS system (and indeed, it still exists in VCS 6.0.2 for Unix) to allow non-root users to run ha* commands to access cluster info, but it shouldn't be necessary with VCS for Windows under secure/SSO mode.  In any case, as I said, there is no halogin.exe in VCS 6.0.1 on Windows, or at least if it does exist it wasn't installed with VCS.

I've just tried setting the environment variables as suggested above, although I couldn't do step 3 and run halogin, but it didn't make any difference.

vssat.exe is not found in any of the paths set in the PATH environment variable by the VCS installer.  I did find it in the C:\Program Files\Veritas\VERITAS Object Bus\eat\bin directory, but running it only gives me this:

C:\Program Files\Veritas\VERITAS Object Bus\eat\bin>vssat showcred

vssat initAtHandle ERROR V-18-7115 Failed To Initialize Authentication Library.

Error initialising the AT Library
 
I don't know if that is an indication of a problem, or just that I shouldn't be trying to use the vssat command.
 
So, to summarize:
I would use non-secure mode if there was such a thing as halogin.exe in VCS 6.0.1 for Windows, which would get me around this issue and allow the scripts to call ha* commands without being prompted repeatedly for the username and password.  However, as there is no halogin, that's not on.
 
Secure/SSO mode seems to be working fine for running the VCS cluster manager GUI, but not for the CLI ha* commands.

mikebounds
Level 6
Partner Accredited

In my previous post I said halogin "works for 5.1 on Windows, because I have used it", but looking back at some docs I wrote, I was actually using halogin in UNIX to run VCS commands on a Windows cluster and I think the Windows cluster may have been unsecure, so halogin may not have existed for VCS 5.1 Windows either.

Bizarrely , this means you MAY get your script to work if you run it from a UNIX cluster as follows:

VCS_HOST=ip_or_host_name_windows_cluster_node
VCS_DOMAIN=foo
VCS_DOMAIN_TYPE=nt
export VCS_HOST VCS_DOMAIN VCS_DOMAIN_TYPE
halogin user password (or you may have to use user@FOO)
hagrp -list

Mike

 


 

 

Ryan_Craig
Level 3

I need to be able to run the script (which in turn runs hastatus, hagrp, etc) from the actual cluster node for my purposes.

I'm seeing some references in various documents and guides to the "Symantec Product Authentication Service(s)", and wonder if that is something I need to install and configure, although it doesn't appear that it is a separate products anymore.

Continuing to investigate...

Ryan

mikebounds
Level 6
Partner Accredited

You are correct vxAT is not a separate product any more for VCS, which is why the directory name that contains vssat is called "eat" - embedded AT.  According to the Windows VCS 6.0 admin guide you can still use vssat commands - see details for a GCO steward, which shows commands you run on VCS cluster node (not steward node):

 

See the Quick Start Guide for Symantec Product Authentication Service for
instructions.

 

 

5. Create an account for the Steward in any authentication broker of the clusters
that are part of the global cluster. All cluster nodes serve as authentication
brokers when the cluster runs in secure mode.
vssat addprpl --pdrtype ab --domain

HA_SERVICES@<fully_qualified_name_of_cluster_node_on_which_t

his_command_is_being_run> --prplname Steward_GCO_systemname

--password password --prpltype service
 
However I suspect this may have been left in the documentation from 5.1 and may not still work - you can test if "vssat showprpl" works, but I doubt it if "vssat showcred" does not work and because the document referenced above "Quick Start Guide for Symantec Product Authentication Service" only seems to exist for 5.1, not 6.0
 
Mike

 

mikebounds
Level 6
Partner Accredited

The Windows VCS 6.0 admin guide also says:

 

Note: On Windows Server 2008, if User Access Control (UAC) is enabled and
configured, all VCS commands must be run in the Run as administrator mode. To
launch the command prompt in the administrator mode, right-click the command
prompt shortcut from the Windows Start menu and click Run as administrator
from the context menu. See the Microsoft documentation for more information
on UAC
So it maybe you can't run VCS commands as a non-adminstrator.
 
Mike

 

Ryan_Craig
Level 3

 

OK, now we're getting somewhere.  Running the command prompt as administrator I am able to run the ha commands.  I've tried turning off UAC in every way possible, however, and still can't run the VCS commands as a non-admin.

I think it was more possible to completely disable UAC in W2k8, but they tightened in up in W2k8R2.  I'm not really sure.

I'd still like to be able to configure it allow non-admin users to run VCS CLI commands, but it looks like it might not be possible.  I'm going to investigate a little more, but I suspect that you have found my answer, and I will return and update this once I know a little more.