cancel
Showing results for 
Search instead for 
Did you mean: 

Ops Center (Linux) and Windows AD Integration

I have Ops Center Server 7.1.0.3 installed on a Red-Hat linux VM, and wish to integrate this with AD to allow users to login with their AD credentials.

I discovered the following in Tech155547

Solution


This solution is verified for OpsCenter server version 7.0.1 + EEB bundle #1 for ETrack 2122784. Install VxAT on the appropriate Windows server.

On the Windows authentication server, run the following command:

C:\Program Files\VERITAS\Security\Authentication\bin>vssat addprpl --pdrtype ab --domain broker --prplname <choose a new user name> --password <choose a password> --credexpiry 0 --prpltype service --is_broker_admin --is_domain_admin

On the Linux OpsCenter server
# cd /opt/SYMCOpsCenterServer/config
# cp security.conf security.conf.original
# cd ../bin
# ./configureAt.sh -installationType 3 -vxssHostname <VBR FQDN hostname> -vxssPort 2821 -vxssPbxPort 1556 -vxssUsername <user name used above> -vxssPassword <password used above> -vxssDomain broker
# ./opsadmin.sh stop
# ./opsadmin.sh start

Login to the OpsCenter UI (it may take a few minutes to get the domains) as the admin (vx) user. Go to User Configuration and click on Add user. Then, click on Existing Domain User. You should see all of your expected domains. Add a user. Log out as admin. At the login screen you should now be able to pull down a list of possible Windows domains seen by the remote broker.

 

I followed the above by installing the VxAT on my Windows Mount Host (W2K8R2) and running the 'vssat addprpl' command (does it matter where it is installed, as long as it is on a Windows machie residing in the domain - or does it have to be a DC ?).  This command completed successfully.  I then followed the instructions above for the Linux OpsCenter server, giving the FQDN of the Windows Mount Host where I had installed the VxAT as the 'VBR FQDN Hostname'.  I ensured that both 1556 and 2821 ports are open between my Linux server and the Windoows Mount Host where the VxAT is installed and running.

Before any of these changes I could log into Ops Center as the admin user using the OpsCenter(vx) domain, after the changes I cannot login at all.  When I give the admin user, its default password of 'password', and leave the domain as OpsCenter(vx) I get:  "User authentication failed. Please enter valid user name and password. If problem persists contact your system administrator." 

I have checked the AT service is running on the OpsCenter server - it is.

Following this I backed out the change by replacing the security.conf with the original - restarted services - and I can now login again as the admin user using domain OpsCenter(vx).

Whilst doing this I notice that in order to get the AT service to run I have to start the service in this order:  AT, PBX, OpsCenter Server.  Any other combination results in the AT service not running.

The security.conf file following the changes is as follows:

vxss.username=opscenter     (the user we created in the addprpl command)

vxss.portnumber=2821

vxss.hostname=trim.xx.yyyy.zz  (changed for this post - is set to the FQDN od the Windows Mount Host where I installed the VxAT)

vxss.installationType=3

vxss.password=APeZ2SJ8n6+0aCIH1yFYig\=\=

vxss.useCorba=true

vxss.pbxportnumber=1556

vxss.initialized=true

vxss.domain=broker

 

I notice an error in the logs as follows which may or may not be relevant:  CORBA Exception - Name: BAD_PARAM  Rep ID: IDL:omg.org/CORBA/BAD_PARAM:1.0 in atbrokeridlenabler.cpp(288)

Th logs also show 'WARNING!!!! Unable to hook up with PBX. PBX related services are not started. Possible causes include PBX Exchange is not running. If PBX related AT servicesare essential please start the PBX Exchange and restart the AT Broker', which I expect as the AT service is started before the PBX service as this is the only way I can get it to start.

I need to be able to add users from the AD Domain, so need to get this linked.

Any advice appreciated.

AJ

 

 

1 Solution

Accepted Solutions
Accepted Solution!

Solution.....

After a lot of 'messing around' and still not being able to get the AD integration to work as required, my solution was to plut Ops Center onto a Windows platform - no issues.

AJ

View solution in original post

1 Reply
Accepted Solution!

Solution.....

After a lot of 'messing around' and still not being able to get the AD integration to work as required, my solution was to plut Ops Center onto a Windows platform - no issues.

AJ

View solution in original post