After an upgrade to QAS 4.0, users are denied access to vasproxyd services that they used to be able to access in VAS 3.5
In VAS 3.5, if either the <service>.allow or <service>.deny service-level access control file was missing, then the corresponding users.allow or users.deny file would be used.
In QAS 4.0, any missing service-level access control file is treated as an empty file and thus treated as though there were no corresponding allow or deny rules for that service.
Run the following commands, where service-name is the name of the service defined in the [vasproxyd] stanza of the vas.conf file, and user-name is an account that should be allowed to use that service. If you see something like the DENIED line in the second case, investigate /etc/opt/quest/vas/users.allow and users.deny and the files in /etc/opt/quest/vas/access.d/ to be sure that the user is allowed to access the service. See the man pages for vasproxyd and pam_vas for more details.
$ sudo /opt/quest/bin/vastool user checkaccess user-name
ALLOWED [user=user-name] [service=login]
$ sudo /opt/quest/bin/vastool user checkaccess -s service-name user-name
Access policy denial. User is not authorized to access this host.
DENIED (access denied) [user=user-name] [service=service-name]
Access Rule = [Only Allow rules defined, user does not match any allow rule]
© 2024 One Identity LLC. ALL RIGHTS RESERVED. Feedback Terms of Use Privacy Cookie Preference Center