NBAC Windows jump server

How to configure role based access control of Microsoft Active Directory users accounts on a Windows 'jump server' Active Directory domain member with NetBackup Access Control (NBAC).

Use case:
- Windows users need administrative access to NetBackup installed on a Red Hat Enterprise Linux (RHEL) master server, but either do not have permission to or do not wish to administrate NetBackup (NB) directly on the Linux operating system.
- Windows users instead have permission to a Windows 'jump server' to remotely administrate the RHEL master.
- The NB administrators need differing permissions based upon role.

Environment:
- NB version 8.0 master server on RHEL version 7. In the examples in this techdoc, this server's hostname is 'chattypuma.acme.krt'.
- Windows Active Directory member 'jump server', hostname 'WIN-2OCNO3URDBQ.acme.krt'
- NB8 installed as a media server without storage units, for the purpose NB master remote administration by Active Directory users.
- One or more Active Directory non-administrative users that will be allowed varying levels of permissions to administrate NetBackup.

To allow Microsoft Active Directory users the ability to run NetBackup commands on the Windows jump server and open the NetBackup Java remote administrator console on the jump server to the RHEL NB master, the following items are required:
- the RHEL 7 NB master must be configured to authenticate Active Directory user accounts otherwise the Windows based NB java remote adminisration console will fail to login to the NetBackup master server.
- the Windows jump server must be a Active Directory member and have NetBackup installed as a media server.
- NBAC must be configured on the master server as a root broker/authentication broker
- NBAC must be configured on the Windows jump server.
- An authentication broker must be configured on the Windows jump server (from the master) to authenticate 'nt' domain users.

Steps:
A. Configure a group and some non-administrative users within Active Directory that will have non-administrative access to the Windows jump server.

1. Create a new Organizational Unit (OU) within Active Directory (AD) named nbOU.
2. Create a security group in AD named 'nbadmins' within the nbOU OU.
3. Create one or more users in AD. Make them a member of the nbadmins group. (In this techdoc, we created a user named 'admin1' and a group named 'nbadmins'.)
4. Create a GPO named GPOnbOU to apply to the nbOU and under Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/User Rights Assignment add the nbadmins group to the 'Allow log on locally' and 'Access this computer from the network'.
5. Test access on the Windows jump server:
   a. Start > Run, type: cmd
   b. Execute: runas /noprofile /netonly /usr:acme\admin1 cmd
NOTE: if this errors with “1385: Logon failure: the user has not been granted the requested logon type at this computer”, it is typically because the admin1 user does not have 'Allow logon locally' and 'Access this computer from the network' rights.


B. Configure SSSD to authenticate Active Directory user accounts on the NB 8 RHEL7 master server:
   1. Ensure the RHEL master uses the same DNS server configuration as the Microsoft Active Directory domain controllers. RHEL has to be able to query DNS for the SRV records pointing to the Active Directory domain controller(s). (The procedure to change the DNS configuration depends upon how networking is configured. Use nmcli for Network Manager managed networks or edit the /etc/resolv.conf file).
   2. Ensure the RHEL master synchronizes to the same time source as the Microsoft Active Directory domain controllers. ('systemctl stop ntpd', 'ntpdate desired_time_server_here.org', 'systemctl start ntpd').
   3. The following packages must be installed in order to use realmd to configure Active Directory authentication in RHEL7: adcli sssd authconfig krb5-workstation krb5-auth-dialog openldap-clients realmd PackageKit. If not installed, run: # yum install adcli sssd authconfig krb5-workstation krb5-auth-dialog openldap-clients realmd PackageKit
   4. Use realmd's 'realm join <domain_name> -U <account_name>' to join the domain:
# realm join acme.krt -U 'Administrator'

Verification points:
- 'realm list' command: [root@chattypuma ~]
# realm list acme.krt
type: kerberos  realm-name: ACME.KRT  domain-name: acme.krt  configured: kerberos-member  server-software: active-directory  client-software: sssd  required-package: oddjob  required-package: oddjob-mkhomedir  required-package: sssd  required-package: adcli  required-package: samba-common-tools  login-formats: %U@acme.krt  login-policy: allow-realm-logins

- use the 'id username@domainname' command to display information about a Active Directory user account, example:
[root@chattypuma ~]# id admin1@acme.krt
uid=198601108(admin1@acme.krt) gid=198600513(domain users@acme.krt) groups=198600513(domain sers@acme.krt),198601107(nbadmins@acme.krt)

5. Verify configuration:
- attempt to login as an Active Directory account:
# ssh -l admin1@acme.krt localhost

– display all objects in Active Directory but limit output to 3 objects (otherwise it will return *everything*):
# ldapsearch -H ldap://WIN-2OCNO3URDBQ.acme.krt:3268 -W -x -b dc=acme,dc=krt -D "cn=Administrator,cn=Users,dc=acme,dc=krt" -z 3 "objectclass=*"

– display info about the user named 'admin1':
[root@chattypuma ~]# ldapsearch -H ldap://WIN-2OCNO3URDBQ.acme.krt:3268 -W -x -N -b "dc=acme,dc=krt" -D "cn=Administrator,cn=Users,dc=acme,dc=krt" "(&(objectClass=user) (sAMAccountName=admin1))"
 Enter LDAP Password:
# extended LDIF # # LDAPv3 # base <dc=acme,dc=krt> with scope subtree # filter: (&(objectClass=user) (sAMAccountName=admin1)) # requesting: ALL ## admin1, Users, acme.krt dn: CN=admin1,CN=Users,DC=acme,DC=krt objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: admin1 distinguishedName: CN=admin1,CN=Users,DC=acme,DC=krt instanceType: 4 whenCreated: 20170426042603.0Z whenChanged: 20170427021849.0Z displayName: admin1 uSNCreated: 49309 memberOf: CN=nbadmins,OU=nbOU,DC=acme,DC=krt uSNChanged: 49730 name: admin1 objectGUID:: 1pJkT1sGBkWUO2dW1LCmrA== userAccountControl: 66048 primaryGroupID: 513 objectSid:: AQUAAAAAAAUVAAAArsEcgF8F3F5/BmEoVAQAAA== sAMAccountName: admin1 sAMAccountType: 805306368 userPrincipalName: admin1@acme.krt objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=acme,DC=krt dSCorePropagationData: 20170427015840.0Z dSCorePropagationData: 16010101000001.0Z lastLogonTimestamp: 131376818925712890
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1

-- note this may or may not work, depends upon AD permissions: ldapsearch -H ldap://WIN-2OCNO3URDBQ.acme.krt:3268 -Y GSSAPI -N -b "dc=acme,dc=krt" "(&(objectClass=user) (sAMAccountName=admin1))"

-- display info about AD user 'admin':
# id admin1@acme.krt     or # id ACME\\admin1

-- test a local login of a AD user 'admin1':
# ssh -l admin1@acme.krt localhost


C. NetBackup NBAC configuration:
   1. Configure NBAC on the master server, execute the following command on the master: # /usr/openv/netbackup/bin/admincmd/bpnbaz -setupmaster
   2. Configure NBAC for the remote Windows jump server, execute this command on the master server:
# /usr/openv/netbackup/bin/admincmd/bpnbaz -setupmedia WIN-2OCNO3URDBQ.acme.krt
Gathering configuration information. You will have to restart NetBackup services on 'WIN-2OCNO3URDBQ.acme.krt' after the command completes successfully. WARNING! Before restarting, please delete AzHandleCache.data file on media server, if exists already at <INSTALL_DIR>\NetBackup\var\vxss directory on Windows or at <INSTALL_DIR>/var/vxss/ on Unix. Do you want to continue(y/n)
  3. Add an authentication broker to the remote Windows jump server, execute this command on the master server:
bpnbaz -SetupAuthBroker WIN-2OCNO3URDBQ.acme.krt
  4. On the master server, change USE_VXSS = AUTOMATIC to USE_VXSS = REQUIRED by executing:
# echo "USE_VXSS = REQUIRED" | bpsetconfig
  5. On the master, change USE_VXSS = AUTOMATIC to USE_VXSS = REQUIRED on the remote Windows jump server by executing this on the master:
# echo "USE_VXSS = REQUIRED" | bpsetconfig -h WIN-2OCNO3URDBQ.acme.krt
  6. Restart all NB services on the master and media server.
  7. Login to the NB Java administration console.
     a. Expand Host Properties, click on Master servers, and then open the master server Host Properties.
     b. Click on Access Control.
     c. On the Authentication Domains tab, under 'Available Brokers:', click the drop down arrow and select the Windows jump server and note the presence of the Authentication Domain named after the Active Directory shortname with Domain Type 'WINDOWS'. If it does not appear, then click Find. Then select it in the 'Available Authentication Domains' list on the right and then click the Add button to make it appear on the right side 'Selected Authentication Domains' list. Then click the Ok button.

*Note1: the 'WINDOWS' type authentication domain does not appear in the available authentication domains list (and/or if the Windows broker hostname does not appear in the Available Brokers dropdown list), will not be present if the commands in steps 2 and 3 above failed or were not executed.
*Note2: As an additional verification, run this command on the Windows jump server to display the authentication broker (figure 2): <install_path>\Veritas\NetBackup\sec\at\bin\vssat showallbrokerdomains

8. Within the NB java admin console, expand Security Management, then expand Access Management, click on
User Groups then in the left-hand pane, right click the group NBU_admin and choose Change.
   a. Click on the Users tab and click New User.
   b. In the 'User' field type the name of the Active Directory user account without the domain prefix.
   c. In the 'Domain' field, type the shotname of the Active Directory domain name.
   d. For 'Domain Type', click the dropdown arrow to set it to 'Windows'.
   e. Leave the 'User Type:' set to 'Individual User' and click Ok.