XYGATE User Authentication Reference Manual

XYGATE
®
User Authentication
™
Reference Manual
Introduction
XYPRO Technology Corporation xxii Proprietary and Confidential
System/SEEP Issues Affecting XUA
This section discusses the SEEP issues that affect XUA.
PHANDLE
There is a field called a phandle in the Safeguard-to-XUA message that identifies the
process doing the logon. In the first message to XUA for a particular logon dialog, it is
correct. In subsequent messages for the same dialog it might be incorrect. To work
around this, XUA uses a keyword called PHANDLE_MISMATCH_CHECK, which has
to have a value of OFF to prevent checking for matching phandle for subsequent
messages.
All Aliases are treated as the Underlying ID
Safeguard erroneously supplies the underlying id of the subject login name for an alias
instead of the alias name during a logon. To work around this anomaly, XUA uses a
keyword called SUBJECT_LOOKUP that, if set to ON, will cause XUA to do a process
info lookup on the logging-on process to get the correct subject login name.
FTP Logon with more than 32-character password
Logon using FTP will not work if a password with more than 32-characters is used to
authenticate. This includes the impersonation logon. To work around this problem, a
password of less than 32-characters must be used when authenticating via FTP.
PQ_SEEP_OBJECT
Due to an anomaly in Safeguard’s SEEP interface, when a user changes his or her
password during logon, Safeguard sends the request to the AUTHENTICATION SEEP
instead of to the PASSWORD SEEP. To work around this, XUA has a keyword
PQ_SEEP_OBJECT that, if pointed to the right PASSWORD SEEP object, instructs
XUA to forward the request to the password SEEP (XPQ).
Safeguard reports
Due to an anomaly in Safeguard, the XYGATEUA process PAID is entered as the
subject ID (the ID making the logon request) in the Safeguard audit trail. XUA records
the subject user correctly in its own audit trail. So if you are required to report on
logons, you should use the XUA audit trail rather than Safeguard’s.
Remote Logon requests
There is a field in the message from Safeguard to the SEEP that tells the SEEP
whether or not the subject is locally authenticated, remotely authenticated or
unauthenticated. Currently, there is a Safeguard anomaly that always sets the value to
“unauthenticated” for local users. This causes all subjects (that is, the person
requesting the logon) to appear as local users. To work around this, XUA uses a
keyword called SUBJECT_LOOKUP which if set to ON, causes XUA to determine
whether or not the subject process is local or remote. If it is remote, it will determine