Remote user profile management administration in a computer network5694595Abstract A security system interface which uses the message passing capability of the distributed application to send messages to remote copies of itself and the security system at the remote system to carry out the remote user profile administration function at the remote machine. A message for a remote user profile administration function is constructed in a syntax used by a distributed application. The message is sent by a local copy of the distributed application resident at a local system to a remote copy of the distributed application resident at a remote system. The message is translated by the security system interface resident at the remote system into a user profile function usable by the security system. Finally, the user profile function is performed by a security system resident at the remote system. In the preferred embodiment, the distributed application is a database management program and the message is a data structure containing information for the remote user profile administration function. Claims We claim: Description BACKGROUND OF THE INVENTION
______________________________________
Remote User Profile Action
Equivalent UPM Function
______________________________________
SQL.sub.-- ADD.sub.-- USER
NetUserAdd
SQL.sub.-- DELETE USER
NetUserDel
SQL.sub.-- LIST USERS
NetUserEnum
SQL.sub.-- GET.sub.-- USER-INFO
NetUserGetInfo
SQL.sub.-- GET.sub.-- USER-INFO
NetUserSetInfo
SQL.sub.-- CHANGE.sub.-- PSWD
NetUserPasswordSet
SQL.sub.-- USER.sub.-- GET.sub.-- GROUPS
NetUserGetGroups
SQL.sub.-- USER.sub.-- SET.sub.-- GROUPS
NetUserGetGroups
SQL.sub.-- VALIDATE.sub.-- USER
NetUserValidate
SQL.sub.-- GET.sub.-- MODALS
NetUserModalsGet
SQL.sub.-- SET.sub.-- MODALS
NetUserModalsSet
SQL.sub.-- ADD.sub.-- GROUP
NetGroupAdd
______________________________________
FIG. 4 is an architectural block diagram of one preferred embodiment of the code modules resident in the client system and the server system. Most of the code modules are preexisting modules used for message transport, however, the figure is included to show one means of many to pass messages between the client and server portions of the remote user profile administrator. Generally, the software configuration is known as the LAN Adapter and Protocol Support (LAPS) and consists of network communication software to support LAN connectivity. LAPS is a combination of Network Driver Interface Specification (NDIS) compliant protocol drivers, NDIS compliant network adaptor drivers, Application Program Interface (API) support software and configuration and installation software for the drivers and is described IBM Local Area Network Technical Reference Order no. SC30-3383. In the preferred embodiment, the UPM APIs are configured as an OS/2 Database Manager Client application 50 in the client system and an OS/2 Database Manager Server stored procedure 52 at the server system. However, many alternative distributed architectures could be used without undue experimentation. The remote user profile administration API modules 50, 52 are coupled to the User Profile Management modules 54, 56 which provide system security at both workstations. Database Manager 62, 64 provides communication facilities to its applications including the security system interface as Database Manager client and server applications 50, 52. Database Manager 62, 64 can communicate with the network either through the NetBIOS 66, 68 or Advanced Program-to-Program Communication for LU 6.2 (APPC LU 6.2) and SNA LAN DLC 70, 72, 74, 76 which are coupled to 802.2 protocol drivers 78, 80, 82, 84 for logical link control communications to the Medium Access Control layer provided by the Network Adapter Drivers 86, 88. The Network Adapter Drivers are software modules that shield the other code modules in the system from the hardware interfaces of the Network Adapters 90, 92 and the Network. FIGS. 5a-5c are flow diagrams of one preferred embodiment of the generic user profile administration process steps which take place on the client system. The process begins in steps 100 and 101 where the interface parameters which the administrator has sent for the remote user profile administration are tested to verify that they are valid inputs. If they conform to the Database Manager format, in step 103, the local system is searched for the remote database, to which the local node can connect: These entries describe certain characteristics of the remote database including information as to which node the database physically resides. In steps 107 and 109, each database directory entry is scanned in search of the node name passed in the parameter list. The node name is in the database directory only if the database is remote, that is on another node. In step 111, if the remote node was found, in step 113, a programmatic logon will occur for the remote node. A programmatic logon puts an entry in the local Requester Access Table (RAT) identifying it as a remote logon. If the node name was not found, in step 111, a programmatic logon will be done in step 115 for the local node which puts an entry in the RAT identifying it as a local logon. In step 119, if the logon was successful, a start using database function is performed for the database associated with the node name. The start using database function is performed to accomplish the connection to the identified node. In step 121, if the start using database function was successful, an input SQL Data Area (SQLDA) is built in step 123 with the pertinent information for the desired UPM function. In step 125, if the input SQLDA was built successfully, an output SQLDA is built in step 127 for communication pertinent data back from the remote node based on the UPM function. In step 129, if the output SQLDA was built successfully, in step 131 a call to Database Remote Application Interface (DRAI) is done to invoke the remote DRAI procedure. In step 133, the SQLCA is examined to determine if the UPM function on the remote node was successful. If the DRAI function was successful, the function will exit to step 139. If there was an error, the SQLDA is examined for further error information in step 137 before existing to step 139. FIG. 6 depicts a preferred embodiment of the Remote User Profile Administration process as it occurs on the server system. The DRAI procedure run on the database server is depicted. In step 200, the local variables are set in step 201, the SQL Data Area built in step 123, is parsed. In step 203, the UPM appropriate function is called based on the UPM action code passed in the INPUT SQLDA in the server remote procedure. In step 205, a test is performed to determine whether the UPM function completed successfully, e.g., a password change successful. If not, in step 207, an error is returned, i.e., the password change was not a success in the SQLCA. In step 209, the output SQLDA is set to indicate the type of error. The syntax for the interface between UPM and Database Manager follows:
______________________________________
int far pascal /* REMOTE UPM ADMINIS-
TRATION */
sqladupm (unsigned char *,
/* Node name */
unsigned short,
/* UPM action to be taken */
void *, /* SQLUPM data structures */
struct sqlca *);
/* SQLCA pointer */
parameters
______________________________________
Node Name--The node name at which the UPM action is to be executed. UPM action--This is the UPM action to be executed. Valid input for this field are as follow: SQL.sub.-- ADD.sub.-- USER--add a user to the UASDB. SQL.sub.-- DELETE.sub.-- USER--delete a user to the UASDB. SQL.sub.-- LIST.sub.-- USERS--list of current users from the UASDB. SQL.sub.-- GET.sub.-- USER.sub.-- INFO--return user information. SQL.sub.-- SET.sub.-- USER.sub.-- INFO--set user information for existing user. SQL.sub.-- CHANGE.sub.-- PSWD--change the password for the user. SQL.sub.-- USER.sub.-- GET.sub.-- GROUPS--return a list of groups a user is a member of. SQL.sub.-- USER.sub.-- SET.sub.-- GROUPS--makes a user a member to a list of groups. SQL.sub.-- VALIDATE.sub.-- USER--validates a user's password. SQL.sub.-- GET.sub.-- MODALS--return user modal information. SQL.sub.-- SET.sub.-- MODALS--set user modal information. SQL.sub.-- ADD.sub.-- GROUP--add a group to the UASDB. SQL.sub.-- DELETE.sub.-- GROUP--deletes a group from the UASDB. SQL.sub.-- LIST.sub.-- GROUPS--returns a list of current groups. SQL.sub.-- GROUP.sub.-- ADD.sub.-- USER--adds a user to a group. SQL.sub.-- GROUP.sub.-- DELETE.sub.-- USER--deletes a user from a group. SQL.sub.-- SET.sub.-- GROUP.sub.-- INFO--sets group information for an existing group. SQL.sub.-- GET.sub.-- GROUP.sub.-- INFO--gets a group's information. SQL.sub.-- GROUP.sub.-- GET.sub.-- USERS--returns a list of users for a group. SQL.sub.-- GROUP.sub.-- SET.sub.-- USERS--sets a list of users as a member of a group. SQLUPM--The SQLUPM data structures is used to supply information relative to the type of UPM action to be taken (add a user, delete a user, change the users password, etc.) and to supply information used by UPM. Some examples of SQLUPM data structures are as follows:
__________________________________________________________________________
struct sqlupm.sub.-- user.sub.-- info
/* USER INFORMATION STRUCTURE */
{
unsigned char userid›8!;
/* user's name */
unsigned char comment›40!;
/* user's comment/description*/
};
struct sqlupm.sub.-- user
/* USER STRUCTURE */
unsigned char userid›8!;
/* user's name */
unsigned char password›8!;
/* user's password */
unsigned char new.sub.-- password›8!;
/* user's new password*/
bool password.sub.-- required;
/* is user's password required*/
unsigned short type;
/* user's type: USER,ADMIN*/
unsigned char comment›40!;
/* user's comment*/
char far * buffer;
/* ptr to sqlupm struct or groupid*/
unsigned short buflen;
/* size of buffer*/
unsigned short entries;
/* number of entries received/sent*/
unsigned short total.sub.-- entries;
/* total entries available*/
};
struct sqlupm.sub.-- modal
/* MODAL STRUCTURE */
{
unsigned short min.sub.-- password.sub.-- length;
/* password length 0-8*/
unsigned short max.sub.-- password.sub.-- age;
/* expiration age in seconds
*/
unsigned short min.sub.-- password.sub.-- age;
/* minimum password age in
seconds */
unsigned short password.sub.-- history;
/* reuse of previous passwords
*/
};
struct sqlupm.sub.-- group.sub.-- info
/* GROUP INFORMATION STRUC-
TURE */
{
unsigned char groupid›8!;
/* group's name */
unsigned char comment›40!;
/* group's comment/description */
};
struct sqlupm.sub.-- group
/* GROUP STRUCTURE */
{
unsigned char groupid›8!;
/* group's name*/
unsigned char comment›40!;
/* group's comment/description
*/
char far * buffer;
/* ptr to sqlupm struct or userid
*/
unsigned short buflen;
/* size of buffer */
unsigned short entries;
/* number of entries
received/sent */
unsigned short total.sub.-- entries;
/* total entries available
*/
};
__________________________________________________________________________
userid--The user ID to be affected by the action. groupid--The group ID to be affected by the action. comment--A 40 character string containing user or group information. password--When action is set to SQL.sub.-- CHANGE.sub.-- PSWD, or SQL.sub.-- VALIDATE.sub.-- USER this field identifies the current password associated with the user ID. With any other action this field is ignored. new.sub.-- password--When action is set to SQL.sub.-- CHANGE.sub.-- PSWD, SQL.sub.-- ADD.sub.-- USER, or SQL.sub.-- SET.sub.-- USER.sub.-- INFO this field identifies the new password to be associated with the user ID. With any other action this field is ignored. password.sub.-- required--When the action is set to SQL.sub.-- ADD.sub.-- USER or SQL.sub.-- SET.sub.-- USER.sub.-- INFO this field can be set to TRUE indicating user must provide/have a password or FALSE indicating user has option not to have a password. With any other action this field is ignored. type--When the action is set to SQL.sub.-- ADD.sub.-- USER or SQL.sub.-- SET.sub.-- USER.sub.-- INFO this field is used to indicate whether the user is a USER or an ADMIN (administrator). With any other action this field is ignored. buffer--This is a pointer to a storage area which can contain a userid, groupid, or a list of user.sub.-- info or group.sub.-- info structures:
______________________________________
Action Buffer representation
Status
______________________________________
SQL.sub.-- LIST.sub.-- USERS
sqlupm.sub.-- user.sub.-- info struc-
output
ture(s)
SQL.sub.-- USER.sub.-- GET.sub.-- GROUPS
groupid›8! string(s)
output
SQL.sub.-- USER.sub.-- SET.sub.-- GROUPS
groupid›8! string(s)
output
SQL.sub.-- LIST.sub.-- GROUPS
sqlupm.sub.-- group.sub.-- info struc-
output
ture(s)
SQL.sub.-- GROUP.sub.-- ADD.sub.-- USER
userid›8! string input
SQL.sub.-- GROUP.sub.-- GET.sub.-- USERS
userid›8! string(s)
output
SQL.sub.-- GROUP.sub.-- SET.sub.-- USERS
userid›8! string(s)
input
______________________________________
Enough storage must be allocated for the expected size and/or number of structures being returned or sent. With any other action this field is ignored. buflen--This field represents the size in bytes of the buffer storage (see buffer). entries--When the action is SQL.sub.-- LIST.sub.-- USERS, SQL.sub.-- USER.sub.-- GET.sub.-- GROUPS, SQL.sub.-- LIST.sub.-- GROUPS, or SQL.sub.-- GROUP.sub.-- GET.sub.-- USERS this field indicates the number of userids, groupids, user.sub.-- info structures or group.sub.-- info structures returned based on the amount of storage provided in the buffer (see buffer and buflen). When the action is SQL.sub.-- USER.sub.-- SET.sub.-- GROUPS, or SQL.sub.-- GROUP.sub.-- SET.sub.-- USERS this field represents how many userids or groupids are being sent. With any other action this field is ignored. total.sub.-- entries--When the action is SQL.sub.-- LIST.sub.-- USERS, SQL.sub.-- USER.sub.-- GET.sub.-- GROUPS, SQL.sub.-- LIST.sub.-- GROUPS or SQL.sub.-- GROUP.sub.-- GET.sub.-- USERS this field indicates the total available number of existing userids, groupids, user.sub.-- info structures or group.sub.-- info structures. With any other action this field is ignored. min.sub.-- password.sub.-- length--When the action is SQL.sub.-- GET.sub.-- MODALS or SQL.sub.-- SET.sub.-- MODALS this field indicates the minimum length a user can enter his password. This length can be from 0 to 8. (ex. If set to 4 then every user's password must be from 4 to 8 in length.) max.sub.-- password.sub.-- age--When the action is SQL.sub.-- GET.sub.-- MODALS or SQL.sub.-- SET.sub.-- MODALS this field indicates the maximum age a password can be before it expires. The value, in seconds, of this field ranges from 0.times.0 to 0.times.FFFFEFFF. If set to 0.times.FFFFFFFF then user's passwords will never expire. min.sub.-- password.sub.-- age--When the action is SQL.sub.-- GET.sub.-- MODALS or SQL.sub.-- SET.sub.-- MODALS this field indicates the minimum amount of time that must elapse before a user can change his password. A value of 0 means that no delay is required. password.sub.-- history--When the action is SQL.sub.-- GET.sub.-- MODALS or SQL.sub.-- SET.sub.-- MODALS this field indicates the number of previous passwords a user is not allowed to use before he can reuse one. The values range from 0 to 8. sqlca--The SQL communication area. This is the area where error information is returned. A series of examples of a system user performing remote user profile administration, according to the present invention is provided in the following examples. EXAMPLE 1 If the system administrator needs to delete a user USERID2, id, e.g., from the user profiles at node DOMAIN5, the sqlupm data structure should be set up as follows: strcpy(sqlupm.sub.-- user.userid,"USERID2"); rc=sqladupm("DOMAIN5",SQL.sub.-- DELETE.sub.-- USER,&sqlupm.sub.-- user,&sqlca); Referring back to FIG. 5 where the interface parameters are examined, the process would check if no name were valid, for example, where valid characters and valid length, at the UPM action requested is valid, that is among the list of actions which may be accomplished remotely, if the UPM action is valid for the SQLMUPM data structure and if all of the required fields in the SQLMUPM data structure were complete. In steps 103 through 121, the process sets up the data base connection to make the remote user profile function call at the remote node. In steps 123 through 129, the information for the data base remote application interface (DRAI) are prepared for the actions specified, in this case SQL.sub.-- DELETE.sub.-- USER, the appropriate UPM function i.e., NETUSERDEL is selected. Next in step 123, the pertinent UPM data is placed in the input SQLDA or the equivalent UPM function. In this case, the UPM data required is the user id. If a response is expected back under remote node, an output SQLDA is prepared in step 127 for returning this information. THE SQSCA is prepared so that return codes may be passed back from the remote procedure. The actual DRAI call will look like this: sqleproc("NETAPI.DLL.backslash..backslash.NetUserDel", vardata, insqlda, outsqlda, & slq * the vardata can be used to pass variable length information to a stored function. It is NULL in this example. In steps 200 to 209, the UPM function is called (NetUserDel) at the remote database location. Any returned information is stored in the SQLDA and any returncodes are passed back in the SQLCA. Upon return from the remote database the client process checks the SQLCA in step 133 for errors. If there are none, then the client receives the data from the SQLDA in step 137, if any. EXAMPLE 2 If the system administrator needs to change the password of a user USERID at node DOMAIN1 from PASSWORD to PASS the sqlupm.sub.-- user data structure should be set up as follows: strcpy(sqlupm.sub.-- user.userid,"USERID"); strcpy(sqlupm.sub.-- user.password,"PASSWORD"); strcpy(sqlupm.sub.-- user.new.sub.-- password,"PASS"); rc=sqladupm("DOMAIN1",SQL.sub.-- CHANGE.sub.-- PSWD,&sqlupm.sub.-- user,&sqlca); the set of commands means to copy the user id to the user id field of the SQLUPM.sub.-- USER DATA STRUCTURE. The password is copied to the password field of the SQLM.sub.-- USER DATA STRUCTURE. The password is copied to the new password field of the SQM user data structure. The SQLADUPM is called to change the password at the main remote node domain1. The procedure as described above in connection with FIGS. 5A through 5B and example 1 are basically repeated. In the code sample above, the SQLADM is called to determine the number of all users at domain1. If the total number of users is greater than zero and the RC is not equal to zero, the bufflen field is set and the SQLUPM.sub.-- USER DATA STRUCTURE to the size of the SQLUPM.sub.-- USER.sub.-- INFO structure for the number of users. The buffer is allocated in the SQLUPM.sub.-- USER.sub.-- DATA STRUCTURE then the SQLADUPM is called a second time to get the list of all users at domain1. The list of all users at DOMAIN1 is printed and the process exits. EXAMPLE 3 If the system administrator would like add a new user USERID2 to the UASDB at node DOMAIN1 with a password of PASS the sqlupm.sub.-- user data structure should be set up as follows: strcpy(sqlupm.sub.-- user.userid,"USERID2"); strcpy(sqlupm.sub.-- user.password,"PASS"); sqlupm.sub.-- user.password.sub.-- required=TRUE; sqlupm.sub.-- user.type=USER; strcpy(sqlupm.sub.-- user.comment,"Userid2 is a user on Domain1"); rc=sqladupm("DOMAIN1",SQL.sub.-- ADD.sub.-- USER,&sqlupm.sub.-- user,&sqlca); EXAMPLE 4 If the administrator would like to receive the current list of users existing on node DOMAIN1 he would use the action SQL.sub.-- LIST.sub.-- USERS. To retrieve all the users, two calls to sqladupm are needed. The first call retrieves the total number of users from which to calculate the buffer size needed for retrieve the users. Then, the second call is made with the buffer size big enough to hold the users being returned. An example:
______________________________________
struct sqlupm.sub.-- user.sub.-- info *user.sub.-- info;
unsigned short rc,i;
rc = sqladupm("DOMAIN1", SQL.sub.-- LIST.sub.-- USERS,
&sqlupm.sub.-- user, &sqlca);
if(sqlupm.sub.-- user.total.sub.-- entries > 0) && (rc == 0)
{
sqlupm.sub.-- user.buflen = sizeof(struct
sqlupm.sub.-- user.sub.-- info)
* sqlupm.sub.-- user.tota1.sub.-- entries;
sqlupm.sub.-- user.buffer = malloc(sqlupm.sub.-- user.buflen);
rc =
sqladupm("DOMAIN1", SQL.sub.-- LIST.sub.-- USERS, &sqlupm.sub.-- user,
&sqlca);
if (rc == 0)
{
*user.sub.-- info = *sqlupm.sub.-- user.buffer;
for(i=1;i<=sqlupm.sub.-- user.entries;i++,user.sub.-- info++)
{
printf("%s %s
/n",user.sub.-- info->userid,user.sub.-- info->comment);
}
}
}
______________________________________
EXAMPLE 5 If an administrator would like to reset an existing user's information, he would use the SQL.sub.-- SET.sub.-- USER.sub.-- INFO action as follows:
______________________________________
strcpy( sqlupin.sub.-- user.userid, "USER1");
strcpy(sglupm.sub.-- user.password, "PASS1");
sglupm user.password.sub.-- required = TRUE;
sqlupm.sub.-- user.type = ADMIN;
strcpy(sglupm.sub.-- user.comment, "User1 is administrator
for dept. 5");
rc =
sqladupm("DOMAIN1",SQL.sub.-- SET.sub.-- USER.sub.-- INFO,&sqlupm.sub.--
user,
&sqlca)
______________________________________
EXAMPLE 6 If an administrator needs to make sure that all users' passwords would expire every thirty days then he would use the SQL.sub.-- SET.sub.-- MODALS action as follows:
______________________________________
/*seconds in 30days = 60sec .times. 60min .times. 24hrs .times. 30days
*/
sqlup.sub.-- modals.max.sub.-- password.sub.-- age = (60*60*24*30);
rc=qladupm("DOMAIN1",SQL.sub.-- SET.sub.-- MODALS,&sqlupm.sub.-- modals,
&sqlca
);
______________________________________
EXAMPLE 7 If an administrator wanted to add a user to a group then he could use the SQL.sub.-- GROUP.sub.-- ADD.sub.-- USER action as follows:
______________________________________
strcpy(sqlupm.sub.-- group.groupid, "GROUP5");
strcpy(userid, "USER1");
sqlupm.sub.-- group.buffer = &userid;
rc=
sqladupm("NODE5",SQL.sub.-- GROUP.sub.-- ADD.sub.-- USER,&sqlupm.sub.--
group,
&sqlca)
______________________________________
EXAMPLE 8 If an administrator needed to add users USER25, USER26 and USER27 to GROUP7 he would use the SQL.sub.-- GROUP.sub.-- SET.sub.-- USERS action as follows:
______________________________________
strcpy(sqlupm.sub.-- group.groupid, "GROUP7");
sqlupm.sub.-- group.buflen = 3*sizeof(userid);
sqlupm.sub.-- group.buffer = malloc(sqlupm.sub.-- group.buflen);
*user = *sqlupm.sub.-- group.buffer;
strcpy(*user, "USER25");
for(j=0;j<=8;user++); /* move user ptr to next userid
location*/
strcpy(*user, "USER26");
for(j=0;j<=8;user++); /* move user ptr to next userid
location*/
strcpy(*user, "USER27");
sqlupm.sub.-- group.entries = 3;
rc =
sqladupm("NODE7",SQL.sub.-- GROUP.sub.-- ADD.sub.-- USERS,&sqlupm.sub.--
group,
&sqlca
);
______________________________________
EXAMPLE 9 If an administrator needs to know all of the users in group GROUP10, then he would use the SQL.sub.-- GROUP.sub.-- GET.sub.-- USERS action. The call must be made twice first to retrieve the number of users and second to get the userids.
______________________________________
unsigned char *user;
unsigned short rc,i,j;
rc = sqladupm("DOMAIN1", SQL.sub.-- GROUP.sub.-- GET.sub.-- USERS,
&sqlupm.sub.-- group, &sqlca);
if(sqlupm.sub.-- group.total.sub.-- entries > 0) && (rc == 0)
{
sqlupm.sub.-- group.buflen = sizeof(userid) *
sqlupm.sub.-- group.total.sub.-- entries;
sqlupm.sub.-- group.buffer = malloc(sqlupm.sub.-- group.buflen);
rc =
sqladupm("DOMAIN1", SQL.sub.-- GROUP.sub.-- GET.sub.-- USERS,&sqlupm.sub.-
- group,
&sqlca);
if (rc == 0)
{
*user = *sqlupm.sub.-- group.buffer;
for(i=1;i<=sqlupm.sub.-- group.entries;i++)
{
printf("%s /n",*user);
for(j=0;j<=8;user++); /* move user ptr to next
userid */
}
}
}
______________________________________
While the invention has been described with respect to particular embodiments above, it will be understood by those skilled in the art that modifications may be made without departing from the spirit and scope of the present invention. These embodiments are for purposes of example and illustration only and are not to be taken to limit the scope of the invention narrower than the scope of the appended claims.
|
Same subclass Same class Consider this |
||||||||||
