The example shows how to verify a permanent user's authentication and authorization properties using LDAP from a given IP address. Run:
tdgssauth -u userconflow -m ldap -i 198.51.100.20
The user's name (-u) is the same as it is specified in a bteq .logon command. The -m option specifies the logon mechanism to use (LDAP in this case). The -i option specifies the IP address from which the user will connect.
1> Please enter a password: 2> Status: authenticated, not authorized 3> Database user: userconflow [permanent user] 4> Authenticated user: ldap://dsa1.example.com:389/uid=userconflow,ou=principals,dc=example,dc=com 5> Audit trail identifier: userconflow 6> Authenticating service: dbssvc 7> Actual mechanism employed: ldap [OID 18.104.22.168.22.214.171.124.1012.1.20] 8> Mechanism specific data: userconflow 9> 10> Security context capabilities: replay detection 11> out of sequence detection 12> confidentiality 13> integrity 14> protection ready 15> exportable security context 16> 17> Minimum quality of protection: 1 (Low) with confidentiality and integrity 18> Options: none
The following explains the output from the command:
|1> Enter a password||When prompted, enter the user's password for the specified mechanism. In this example, enter the user's LDAP password because the specified mechanism is LDAP. If KRB5 is the specified mechanism, enter the user's KRB5 password.
Use -w and specify the user's password on the command line to avoid being prompted for the password.
It is not recommended to specify the user's password on the command line.
|2> Status: authenticated, not authorized||The user authenticated successfully, but the user does not have a mapping to an explicit Vantage user in the directory.|
|3> Database user: userconflow [permanent user]||The database user's name and the database user is a permanent user (the user was created in the database by the DBA).|
|4> Authenticated user: ldap://dsa1.example.com:389/uid=userconflow, ...||The identity of the user in the directory server and the server that authenticated the user.|
|5> Audit trail identifier: userconflow||The user's audit trail identifier used in event logs caused by a session logged on as this user.|
|6> Authenticating service: dbssvc||The service name of the service used to authenticate the user. The service is configured in the <LdapConfig> section of the TdgssUserConfigFile.xml file.|
|7> Actual mechanism employed: ldap [OID 126.96.36.199.188.8.131.52.1012.1.20]||The name and Object Identifier (OID) of the actual authentication mechanism used to authenticate the user.
The TDNEGO mechanism reports the actual mechanism that it selected to authenticate the user. Other explicitly named mechanisms report themselves here.
|8> Mechanism specific data: userconflow||The mechanism specific data. This data is used by other parts of the system during the login process and is not used by TDGSS. Usually this provides the name of the user from the -u command line option.|
|10 - 15> Security context capabilities:
out of sequence detection
exportable security context
|These lines show what a particular security context provides. The security context is the one established for the named user using the specified mechanism.|
|17> Minimum quality of protection: 1 (Low) ...||The minimum QoP that the user is required to use for the duration of the session. In this example, the directory configuration shows that this user needs to use, at the very least, a low strength confidentiality QoP. The database enforces this and if the session uses a less secure QoP than the one specified the user's session is terminated.|
|18> Options: none||The connection options in effect for this user. In this example, the word none indicates that this is a normal connection. This value may contain has-policy or no-direct-connect. has-policy says that the user must use only a plaintext connection to the database and is used for very specialized purposes. no-direct-connect says that the user is not permitted to connect directly to the database.|