United States Patent
`l)utcher et al.
`
`[54] USER PROFILE STORAGE ON AND
`RETRIL'VAL lrRORI A NON-NATIVE SERVER
`DOMAIN FOR USE IN A CLILNT RUNNING
`A NATIVF. OPFRATINC SYSTFM
`
`[75]
`
`Inventors: David Paul Dutcher, Scott Alan
`Lenharth, both of Austin, James
`Michael Rolette„,lr., Roun&i Rock;
`Stanley Alan Smith; Courtncy Joseph
`Spooncr, both of Austin, all of Tex.
`
`[73] Assignee:
`
`Internatinnal Business Machines
`Corporation, Annonk, N.Y
`
`[Zl] Appl. No: 08/888,735
`Jul. 7, 1997
`Filed:
`
`[Z2]
`
`[52] U.S.Cl.. 713/200; 713/2(l 1, 713/202
`Int. Cl.'............... G06F 13/00
`
`[51 I
`
`[58]
`
`Irield of Search ............................. 395,'186, 187.01,
`395&188.01, 200.59, 200.57, 380 25, 707&10,
`r). 713/200 201 202
`
`IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII
`US006044465A
`[i i] Patent Number:
`l)ate of Patent:
`
`6&044&465
`Mar. 28, 2000
`
`[45]
`
`«««5,3io
`«,O2«066
`«,790,790
`«,812,843
`
`9,'1996 Thermer et al
`4 &ovi Pike et al
`8,'1998 Smith et al.
`9 1998 Yamaraki et al
`
`. 395/20&&.09
`39:5/hl6
`. 395/20&&.36
`39«/67&&
`
`OTHER PUBLICATIONS
`.Jacobs and lbaner, "Remote User Profile Management
`Arlministration in a Computer Network", IBM Database,
`Dcc. 1993.
`Tate, KA, "Aggregate User Prolile,'esearch Disclosure
`No. 347, Mar. 1993.
`Priman Exam/i&er~y V. Hua
`Arrorne&l Agenr, or Erin&M)avid ll..tudson; .Jeffrey 8
`I.aBaw
`
`[57]
`
`ABSTRACT
`
`A user is authenticated at a client machine running a native
`opcratin system. Authentication may bc cffcctcd from onc
`or more non-native server domain« includin, without
`1&milation, a Server Message Block (SMB) server domam, a
`DCL''eil, or some other non/Windows Nl'erver rlomain
`I'ollowing successful authentication, a user account
`is
`rlynamically established or updated at thc client by retriev-
`ing from the scrvcr user information and a sct of 'group"
`pnvilcgcs associated v ith thc authcnticatcrl user. A "user
`prr&lik" is re&neve&1 from the non-nauve server domam and
`to estabhsh at
`the client
`a user deal top and any
`use&i
`preferences associated with the user
`
`20 Claims, 7 Drawing Sheets
`
`[56[
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`ll&1993 lani« .......................
`5.263,165
`7&1994 Page et al..............
`«,329 619
`5.369,778 ll&1994 Saa Soocie «& al.
`12/&995 Molar et al..
`5,475,819
`7&19'&6 L'«hei e& al.............
`5.«3«,375
`
`711/163
`3&&5,200 33
`707/103
`.. 3'&5&2&/()33
`......... 395/500
`
`15'inLogon
`
`120
`
`124
`
`122
`
`Google Exhibit 1054
`Google v. VirtaMove
`
`

`

`U.S. Patent
`
`Mar.28,2000
`
`Sheet 1 of 7
`
`6,044,465
`
`CLIENTS
`
`SERVERS
`
`120
`
`14
`
`16
`
`120
`
`17
`
`14
`
`

`

`U.S. Patent
`
`Mar.28,2000
`
`Sheet 2 of 7
`
`6,044,465
`
`SERVER(S)
`
`14
`
`30
`
`32
`
`36
`
`38
`
`120
`
`START
`
`EXISTING USER ACCOUNTS
`
`DISCOVERY OF SERVER
`AUTHENTICATION LOCATIONS
`
`CREATE USER ACCOUNT
`
`IMPLEMENT AUTHENTICATION
`DISCOVERY POLICIES
`
`RETRIEVE AND ESTABLISH
`USER PROFILE
`
`42
`
`LOGON ATTEMPT
`
`PRESENT USER WITH
`AUTHENTICATION OPTIONS
`AND/OR HAVE USER
`INITIATE NEW DISCOVERY
`
`AUTHENTICATE USER
`AT SELECTED DOMAIN
`
`WORK
`
`44
`
`DONE?
`
`46
`
`YES
`
`MANAGE USER ACCOUNT
`
`END
`
`

`

`U.S. Patent
`
`Mar.28,2000
`
`Sheet 3 of 7
`
`6,044,465
`
`41
`
`43
`
`45
`
`47
`
`ACCESS EXISTING
`USER ACCOUNT
`
`EXECUTE AUTHENTICATION
`CALLS AGAINST THE
`EXISTING USER ACCOUNT
`
`EXECUTE REQUESTS TO
`ACCESS "GROUP" INFORMATION
`AND USER ACCOUNT
`INFORMATION AGAINST THE
`EXISTING USER ACCOUNT
`
`EXECUTE USER PASSWORD
`CHANGE AGAINST THE USER
`ACCOUNT IF REQUESTED
`
`END
`
`FIG. 5
`
`

`

`U.S. Patent
`
`Mar. 20, 2000
`
`Sheet 4 of 7
`
`6,044,465
`
`START
`
`84
`
`HAS
`CLIENT RECEIVED
`NOTICE OF A SUCCESSFUL
`AUTHENTICATION
`
`YES
`
`CREATE/UPDATE USER ACCOUNT
`
`ISSUE REQUEST TO SERVER TO
`RElRIEVE USER INFORMATION
`AND IDENTIFY EACH GROUP
`10 WHICH USER BELONGS
`
`RETRIEVE USER AND GROUP
`INFORMATION FROM SERVER
`
`CREATE MIRROR
`GROUP REPRESENTATION
`
`LINK USER ACCOUNT
`TO LOCAL GROUP(S)
`
`END
`
`86
`
`88
`
`90
`
`92
`
`PRESENT LIST(S) OF
`SERVER DOMAINS
`
`PROMPT ADMINISTRATOR
`TO SELECT DOMAINS FOR
`PRESENTATION TO USER
`
`ADD NEW LOCATION(S)
`(OPTIONAL)
`
`INVOKE RESTRICTION
`AGAINST USER ENTRY OF
`AUTHENTICATION LOCATIONS
`
`INVOKE RESTRICTION
`AGAINST USER INITIATION OF
`NEW DISCOVERY REQUEST
`
`END
`
`74
`
`78
`
`80
`
`91
`
`93
`
`95
`
`99
`
`101
`
`

`

`U.S. Patent
`
`Mar.28,2000
`
`Sheet 5 of 7
`
`6,044,465
`
`100
`
`WinLogon
`
`120
`
`124
`
`122
`
`

`

`U.S. Patent
`
`Mar. 2tt, 2000
`
`Sheet 6 of 7
`
`6,044,465
`
`IBM Networks Client Properties
`
`General
`
`Advanced
`
`SMB Driver
`
`Customize the list of other domains or cells that will be available
`for selection on the Logon window.
`
`Domain/Cell name:
`
`Display at
`
`logon
`
`Q4 Enable domain name searching on the Logon window.
`
`Q~ Enable domain name entry on the Logon window.
`
`

`

`U.S. Patent
`U.S. Patent
`
`Mar.28, 2000
`Mar.28,2000
`
`Sheet 7 of 7
`Sheet 7 of 7
`
`6,044,465
`6,044,465
`
`Logon Information
`
`G Enter a user name and password that
`
`is valid for this system.
`
`
`
`
`
`
`
`
`
`
`possvorés§—§[J
`
`Domain;=(TF [iscover
`
`
`
`FIG. 15
`
`

`

`USER PROFILE STORAGE ON AND
`RETRIEVAL FROM A NON-NATIVE SERVER
`DOMAIN IzOR USL'N A CLIENT RUNNING
`A NATIVE OPL'RATING SYSTEM
`
`BACKGROUND OF THE INVENTION
`
`1. Tcchnical Field
`The present invention relates generally to computer net-
`worl s and more particularly Io authenncanng a user of a
`client machine running a native operating system against a
`user account held at a non-native server domain
`2. Description of thc Rclatcd Art
`The chen&-server model of compunng is a well-known
`environment. In the model, the user of a computer utilizes a
`"client'* system 'I'he client system runs any of a number of
`computer operating systems to mana c Ihc basic functions
`file, cxccutin
`that users cxccutc (such as acccssin
`programs, system administrauon and the like) as well as to
`serve as Ihe base against which programs are wntten.
`Well-1 nown client operaung systems include Microsoft
`Windows ikl, Windows for Workgroups, Windows &3S,
`333M% OS,SCw Warp, Apple Macintosh, DOS, many varia-
`tions of UNIX, and Microsoft Windows NT. The client
`
`system scrvcs as thc user's worl station, and it may cxccute--'rogramsas well as store some user dais.
`
`The server system can also run any of a number of
`computer operating systems. Well-kno&vn server operat&ng
`systems include Novell Netware, IIIM OS/2 Warp Server,
`IBM AS,'40(l , Microsoft Windows NT, and many varia-
`tions of OSF UNIX. Thc scrvcr syskm is acccsscd by the
`chen& system for specific luncuons. The tune&rona include,
`but are not limited Io, storage and re&naval of data, storage
`and execution of applications, anil storage of and access to
`user information.
`Industry standarrls have bccn dcvclopcd (for critical anil
`common functions) to aid in the access from difierent types
`of chen& systems Io diferent types of server systems. The
`use, of these stamlarrls on ihe chen& aml server alford users
`the opportunity to carry out functions in a nmsistent manner
`on a variety of common client anil server operating systems
`Onc of thc activities that has bccn standardized is the
`cationn.
`"authentication'f users Authentication rcfcrs to thc pro-
`cess in which a user is validated as being able to complete
`a logon and&or access a system. Standartl protocols have
`been delined within the X&Open Server Massa e Block
`(SMI3) specitication and the Open Systems I oundation
`(OSI') Distributed Computing L'nvironment (33(IL) specifi-
`
`35
`
`While many products and operanng systems have been
`developed that uuhze the standard protocols, not all prod-
`ucts have used the stanrlarrls When this occurs, e&ther
`additional work must be done by the other operating system
`to implement the unique commands use&I by a vendor, or
`access to thc other ncw system and&or product is not allowcrl
`if thc unique commanrls arc not made availablc to other
`vemlors. When the commands and&or protocol are not made
`available, that aspect ol. Ihe system andior product is some-
`times characterized as heing *'closed'(
`Thc Microsoft Windows NT operating system is bccom-
`a dominant client system in many cntcrprisc computer
`in
`networks. Because of the "closed'ature of Windows NT,
`a user of a client machine running this operating system may
`only lo ~ on against an account held at the machine, at a as
`server running Ihe Windows NT operating system, or at any
`other servers that are "trusted'* by the N'I'erver that the
`
`60
`
`client is configured against. Only these options are supplied
`to the user during the logon process, and there are presently
`nn dncumented interfaces to allow user authentication from
`nnn-native server domains. Moreover, in known Windows
`NT systems, a local NT user account is required for logon
`and subscqucnt user actions. Thus, thc NT user account
`required for iniual authenticauon may exist only on an NT
`client or in an NT server domain. This closed architecture
`eliminates the ability to dn full central&zed arhninistration
`frnm a source other than an NT server environment, and
`there is no open capability to create a necessary user account
`based on information rcccivcrl from a user account provider
`other than Windows NT.
`Windows NT systems do have the capability ol storing
`anil retrieving a so-called '*user profile" which typically
`comprises a user desktop definition and preferences. A user
`profilc is typically stored on cithcr a local Windows NT
`client or a Windows NT scrvcr. Even though Ihc Windows
`NT server supports the Server Message Block (SMB)
`protocol, storage and retrieval of users proliles I rom general
`SMB servers domains is no&supported In other words, there
`is nn known mechanism for user prohle storage on and
`retrieval from systems other than native Windo&vs N'I'. 'I'hus,
`if primary authentication of a Windows NT client at 3 source
`other than a Windows NT scrvcr is to bc achicvcd, it would
`be ilesirable Io have an associated mechanism Io store and
`re&neve user profiles on lile systems other than nauve
`Windows NT (e.g., SMB server domains and servers sup-
`pnrting Ilistributed I&ile Services (DI S)).
`Thc prcscnt invention solves this problem.
`
`SUMMARY OF THE INVENTION
`It is a primary object of this invention provide user profile
`storage on and retrieval from sclcctcd file systems.
`It is another pnmary obl act ol the present invention to use
`such a "retneved" user prolile at a client to enable a user to
`"see*'
`familiar desktop irrespective of what particular
`machine the user lo on occurs.
`is still another primary object of this invention to
`It
`provide desluop and environment consistency for users who
`authenticate themselves against accounas held at non-nauve
`server domains
`Yct another important object of this invention is to obviarc
`tying a sin lc user to a single workstation in a hctcrogcncous
`client-server environment so that users can '"roam" around
`the networl and use any of. a set of workstauons while sull
`allnwing such users to retain their own unique desktops
`It &s a more general oi&jeer of this invention to facilitate
`pnmary authentication of a user of a chent running a native
`system at a source other than a native scrvcr
`opcratin
`&lorn sin.
`It is a more particular object of this invention to authcn-
`ucate a Wimlows NT user at an SMB server domain and then
`to download and mstantiate on the Wimlows NT client a user
`profik supported on Ihe SMB server domain.
`is another more particular object of this invention to
`It
`authenticate a Windows N I'ser at a DCL'ell and then to
`rlownload and instantiate on thc Windows NT client a user
`profilc supportcrl on a DCE Distributed File System (DFS)
`&lorn sin.
`According Io the mvention, a user is authenticated at a
`client machine running a naive operating system. Authen-
`ucauon may be ellected from one or more non-nauve server
`dnmains including, without imitation, a Server Message
`Block (SMB) server domain, a 33('L Cell, nr some other
`
`

`

`non-Wimlows NT server domain. The various non-nahve
`server domains are *'discovererl" by issuing requests from
`the client to one or more of the servers in the network
`Iiollmving successful authentication, a user account
`is
`dynamically cstablishcd at thc client by rctricving from the
`scrvcr user information and a sct of "group" privileges
`associated with the authenhcated user. Thereafter, a user
`prolile supported on the non-nanve server dommn is
`retrieved and established on the client The pnifile generally
`includes the user's desktop rlefinition (e g, colors, patterns,
`accessibility options, desktnp nigtects) and user information
`specific to diffcrcnt applications that thc user cxccutcs
`Thc foregoing has outhncd some of thc morc pcrtincnt
`objects and fcaturcs of thc prcscnt invention. Thcsc objects
`should be construed to be merely illustranve of some of the
`more prominent features and applicauons of the invention.
`Many other benehcial results can be attained by applying the
`disclosed invention in a different manner or modifying the
`invention as will bc dcscribcrl. Accordingly, other objects
`and a fuller understanding of thc invention may bc had by io
`referring to thc following Dctailcd Description of thc Pre-
`ferred Embodiment.
`
`ic
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`For a more complete underinanding of the present inven-
`tion aml the advantages thereof, reierence shoulil be made to
`the following Detailed Descnption taken in connection with
`the aceompanymg drawings in ivhich
`is a block diagram of a representative computer
`I'IG I
`network in which thc prcscnt invention is implcmcntcd,
`FIG. 2 is a block rliagram of a known "Pnor
`
`Art'echniquewherein a user of a Windows NT clrent machine
`
`ts authenucated against an account held at a Wmilows NT
`server domain;
`I'IG 3 is a block diagram of the present invention wherem
`a Ingon mechamsm is provided in the client running a native
`operatin system to facilitate authentication of a user of the
`client machine against an account held at a native or
`non-native scrvcr rlomain,
`FIG. 4 is a flowchart of a preferred method of thc prcscnt
`invention to enable a user of a Windows NT account to be
`auihenticated against an account held at a native or non-
`native server domain,
`I'IG 5 is a flowchart of a preferred routine for accessing
`user account information on a server domain;
`FIG. 6 is a flowchart of a prcfcrrcd routine for discovery
`of authentication locations according to thc prcscnt inven-
`tion;
`FIG. 7 is a Ilowchart illustraung how an ailministrator
`the client followrng the
`may manage ihscovery policy at
`discovery of authentication locahons in FIG. 6,
`I'IG 0 is a flowchart illustrating how a user account is
`established dynamically follnwing authentication of the
`user;
`FIG. 9 is a flowchart illustrating a routine for cstablishin
`a user profile at thc client,
`I'IG 10 is a ffoivchart illustrating a preferred technique
`for establishing a user profilc at thc client machine;
`I'IG 11 is a flowchart illustrating a "maintenance* routine
`accordin to the present inventinn;
`I'IG 12 is a block diagram illustrating a preferred arch&-
`tecture of the present invention;
`FIG. 13 is a representauon of a General Properues display ss
`screen used to facilitate administrative management of dis-
`covery policy;
`
`ss
`
`FIG. 14 ts a representauon of an Advanced Propernes
`display screen used to facilitate administrative management
`of discovery pnlicy; and
`FIG. 15 is a rcprcscntation of a Logon Panel display
`screen in accordance with the present invenuon.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENT
`I IG I illustrates a computer network having one or more
`"client*'achines 10 and one or more "servers'* 12. Atypical
`client machine 10rt is a personal computer or workstation
`running an Intel processor 14 and thc Microsoft Windows
`NT 4.0 operating system 16. For convcnicncc hcrcin, a
`machine conligured m this manner is somenmes reierred to
`as a "Wimlows NT client'. Any other type of hardware
`platform that runs Windoivs NT operating system may be
`used as the client According to the present invention, the
`client also includes an application 10, sometimes referred to
`hcrcin as a "Primary Logon Client," which provides certain
`additional functionality to achicvc thc objects of thc prcscnt
`invention. Each client has basic networking hardware to
`establish a connecnon out to a server. Thus, Ior example, a
`client may have a I'('Pilp or NE'I13IOS connectinn to the
`netwnrk running over a token ring or Lthernet adapter
`Typically, a server in thc computer network is another
`personal computer or workstation platform that is Intcl-,
`PowerPC((3c or RISC -based, ami
`includes an operating
`system such as Winriows( NT 4.0, IBM OS,'2 warp
`Server, AIXips or the like At least one server IZrt
`in the
`computer network supports the Microsoft Windows Nl'
`0
`this platform is somctimcs
`platform. For convcniencc,
`referred to as a "Windows NT scrvcr". When a user sccl s to
`bc authenticated to scrvcr 12a from a Windows NT client,
`i.e. a client machine running the Microsoft Windows NT
`operating system, the server 12a is said to be "nanve" since
`is running the same operating system as the client. A
`it
`"non-native* server is thus a server platform (e.g, a personal
`computer) runnin an operating system that is diff'crent than
`the operating system running on thc client system accessing
`the scrvcr. Given a Windows NT client, cxamplcs of such
`limitanon, IBM OSi2 warp
`servers include, without
`Server, IBM LAN Server , other types of Server Message
`Block (SM13) servers, as ivell as operating systems that run
`open Systems I'oundation (OSI ) Distributed Computing
`Environment (DCE) software. An cxamplc of thc latmr is a
`D('E ('cll running Distributed File System (DFS).
`In the prior art, a user of a Winrlows NT client 10n is
`typically authenncateri by a Windows NT server 12u as
`shown in FIG. Z. This propnetary client-server linkage is
`created bv the fact that both the client anti server run the
`same operating system (e.g, Microsoft Winrlows N'I'
`0)
`anti use an undocumented set of interfaces for the function
`In this known technique, a user
`of user authentication.
`sccking to be authcnticatcrl at
`thc chcnt simultaneously
`premes the "control', "alt'* ami "delete" keys oi the key-
`boarii to initiate a lo on session. This schon calls a *'graphi-
`cal identification anti authorization'odule 15 (somenmes
`referred tn as "gina**) that controls the logon sequence 'I'his
`module displays a logon panel display box 17 to the user and
`prompts for entry of a usend anil passv ord. In a known
`embodiment, thc logon panel typically cnablcs thc user to
`logon against an account held at the client machine itself., or
`to logon against an account held at the NT server. The gina
`moiiule 15 confro(a what servers show up in the logon panel
`dialog box 18 In particular, when the N I'lient is installed
`the system administrator can point
`in the network,
`the
`
`

`

`worl stahon against an NT domain name, aml that domain
`name then shows up as an authentication option in addition,
`the administrator of the N'I'erver may conhgure the server
`so "trusted'* authentication domains are displayed
`In this known technique,
`the gina module 15 ughtly
`controls the locations that are available Ior authenucatron to
`include the local NT workstation use if, the remote NT server
`12a, and any other servers that are "trusted'* by the NT
`server that the client is configured against. (generally, only
`these options arc shown to thc user sccking authentication,
`and thcrc arc no intcrfaccs availablc to enable thc user to be
`authenticated from non-native server dom un«. The present
`invention atltlresses this problem.
`
`In particular, and as seen in I'l(k 3, a new gina module15'srey'stcrcd instead of thc gina module 15. This cnablcs the is
`
`Windows NT client user to bc authenticated against an
`account held at a non-native scrvcr domain 19 AS uscrl
`herein, a "non-nauve server domain'efers to a database of
`user account information retained at a given server runnin ~
`is different
`than the operating
`an operating system that
`the client system 'I'he term "heterog-
`system running at
`to describe an envimnment m
`enous** is commonly userl
`which thc client operating system and scrvcr opcratin
`system arc diffcrcnt. This type of cnvironmcnt is common in
`the client-server model. Ln contrast, the term "homogenous"
`ts commonly used to descnbed an environment in which the
`client operating system and server operating system are the
`same
`A non-native scrvcr domain is typically supported on a
`non-nauve server. Thus, where the user seel s authenhcahon
`from a Windows NT chent, a non-nauve server domain
`limitation, any Server Message Block
`includes, without
`(SMI3) server domain (e g., IBM Warp Server 4.0), a DCL
`I'ile System (Dl'S)
`in which Distributerl
`Cell
`is
`implcmcnted, or other known domains such as UNIX
`domains. This is illustratcrl in HG. 3. Of course, the com-
`puter network can aLso include a Windows NT server
`domain 12« if authenucauon is sou ht from a native server
`domain.
`In thc prcfcrrcd cmbodimcnt,
`thc client machine is a
`Windows NT client, although one of ordinary skill in thc art
`should appreciate that teachings of this invention arc also
`applicable whenever the client machine is runnm ~ a nauve
`operatm ~ system anil there is a desire to authenucate a user
`against an account held at either a native or non-native
`server domain Some of the features of the present invention
`(e g., the "discovery'* function as described in lq(l 6) are
`implcmcntcd cvcn when thc client-scrvcr paradigm remains
`homogcncous.
`the present
`Thus, according to a primary goal of.
`invention, the homogeneous N'I'lient-server environment
`is uncoupled so that a user of a Windows Nl'lient (by way
`of cxamplc only) may bc authenticated by a non-native
`scrvcr. With rcspcct to authentication of thc Windows NT s
`is "hetero enous.
`chenL, Lhe client-server environment
`the chent gives the user access to
`resources on the client system, and when this is done via an
`it also gives the user
`account definition held at a server,
`access to resources at the server network via a single logon
`Thc prcscnt invention thus cnablcs a user to sclcct a par-
`ticular location against which hc or shc dcsircs to be
`authenticated. Thus, the user*a account informauon may be
`retained at the non-nauve server domain m additron to (or
`instead ol) the Windows NT server normally coupled to the es
`Windoivs N'I'lient in a cinsect manner. The user's single
`userid and password are then held out at a non-native server,
`
`n
`
`'uthenticauonat
`
`the Itke. This
`such as a Warp Server,
`a DCE cell, or
`information may also be retained at a native server domain.
`I IU 4 is a flowchart representing various "high level'*
`operations of the present invention The method begins at
`step 28, which signities the existence of a account on
`selected server domain systems in the computer network. AS
`used hcrcin, a user account typically includes, but is not
`limited to, a user identification (uscwd), a password for thc
`userid, and some representation of privileges for the user. At
`step 30, server locations at ivhich a user may be authenti-
`catcrl are "discovered'* usmg a rliscovcry mechanism of thc
`invention. This mechanism is rlcscribcd in detail below. At
`step 32, the administrator may manage or control authenti-
`cation discovery policies that are later prov«led to a user
`seeking authentication. Steps 28, 30 anil 32, heing admin-
`istrative in nature, generally occur before a given user seeks
`to logon against a user account maintained in the system,
`althou h step 30 may bc pcrformcrl by a user from thc logon
`scrccn itself during thc authentication process. At step 34, it
`is assumed that a user seeks to logon against an account
`associated with that user and held at a given server m the
`network. This fiegins the logon processing,. At step 36, the
`user is presented with the names and locations of the server
`domains available for authentication, or the user may initiate
`his or hcr own 'discovery" of such information (if that
`capability is enabled).
`Following selection of a domain, thc user is then authcn-
`ticatcd at step 38. Such authentication may lic at a native or
`non-native scrvcr according to thc prcscnt
`invention.
`Typically, this authentication is a process in which the, usend
`and password are provided to a user account database for
`validation Upon successful vahdation, a positive conhrma-
`tion is received for the authentication and the user process-
`to continue. Thcrcaftcr, at step 40, when
`ing is allowcrl
`authentication is at a non-native scrvcr, a "local" user
`account is crcatcd dynamically (or, altcrnativcly, updamd if
`the user account already exists) at the client machine. This
`is a Windows NT account in the prelerred embodiment. At
`step 42, the NT user profile is retrieved and established at the
`client to enable the user to initialive a personal "rlesktop'*
`and to implement certain access "prcfcrcnccs't thc client.
`Thc "user profile*'which normally rlift'crs from thc "user
`account" described above) thus prcfcrably includes, without
`limitation, a deal top delinition and a set of prelerences for
`the user. A user prolile is created as the user changes
`appearance and preferences ivhile using the client. 'I'hus, for
`example, the display screen format is accessed anil altered
`through known techniques (e g, the Winrloivs *95 desktop
`"Prcfcrcnccs').
`Returning back to the flowchart, the user then proceeds to
`rlo work at
`thc client machine. This is step 44 in thc
`flowchart. When thc user is done at thc NT client (typically,
`but not necessarily, at logoft), as indicated by a positive
`outcome of the test at step 46, the NT user account Ls then
`"managed" at step 48 by policy established by the atlmin-
`istrator Such management typically involves maintaining,
`deletuig or disabling the dynamically-created local N'I'ser
`account, although other operations may also bc carried out.
`This completes thc high Icvcl processing.
`illustrating, how a user
`I IU 5 is a simplihed flowchart
`account is accessed in a given scrvcr domain. For illustrative
`purposes, it is assumcrl that the scrvcr rlomain is non-native
`such that a user of the Windows NT client machine may be
`authenticated against the account held at a non-nauve server
`ilomain. The non-native server domain is assumed to be any
`Server Message Block (SMI3) server, such as II3M Warp
`Server 4 0 or a D('C Cell (such as OSIi II('E running DI'S),
`
`

`

`ts
`
`io
`
`or any other type of non-native server that implements the
`appropriate commamls.
`There are many mechanisms for creatinn of user accounts
`on different types of non-native server domains. 1'his inven-
`tion allows usage of these exisnng accounts such that no
`unique actions (e. ~, changing ol. the user account or creation
`of a ncv user account) arc rcquircd on thc non-native scrvcr
`domain. By using existing authentication rcqucsts and
`requests to retrieve user account information from the non-
`native server, support has been extended to SMB server
`domains, DCE Cells, and other non-native scrvcrs.
`The routine illustrating how the user account is accessed
`from a client system begins at step 41 with thc user account
`on the non-native scrvcr having bccn previously crcatcd. At
`step 43, and as iflustratcd below, rcprcscntativc authcnttca-
`tron calls are executed against the existing user account. The
`rouune then conunues at step 45, wherein existing requests
`to access user account information anil "group'* information
`are executed against
`the existing user account.
`I IG 8
`describes this process in morc detail. Finally, at step 47, a zo
`user password change is optionally cxccutcd against thc user
`account on thc non-native scrvcr domain. This allows for
`these password changes lrom a nanve chant to a non-nanve
`server domain.
`FIG. 6 is a high level tlowchart illustraung the operation
`of the discovery mechanism of the present mvenuon. Fur-
`ther implementation details are set lorth below. Preferably,
`this mechanism is resident on the client machine and func-
`tions to compile unique "lists'* nf native anil non-native
`authentication locations from which thc user may bc authcn-
`ticated. Thc discovery mechanism is very advantageous
`given the inherent imitations in how potential authenuca-
`tion locations are determined in the pnorart. Prelerably, the
`discovery mechanism includes documentetl "interfaces'o
`which third party authentication service providers may zs
`implement to enable the discovery and storage of discovered
`locations on thc client system. Thc discovery routine may be
`activated by an administrator when thc system is hrst
`installed or during system conliguratron (or
`re-conligu ration), or it may be acnvated by a user during the ao
`logon process itself. The routine begins at step 66 (cuber
`from an administrative interface or the logon screen) with
`the gina module 15'ontrolling issuance of a set of calls to
`scrvcrs on the network to dctcrminc potential authentication
`locations. Thc routine continues with thc kst at step 68 to as
`detcrminc whether a particular scrvcr domain rcsponrling to
`a call is native If the outcome ol the test at step 68 is
`posinve, the routine conunues at step 7U to add the domain
`to a list of native server domains maintained at the chent
`machine If the outcome of the test at step 68 is negative,
`indicating that thc scrvcr rlomain is non-native, thc routine
`thc non-native scrvcr to the
`continues at step 72 to adtl
`appropriate list of non-native scrvcr domains maintainctl at
`the client. A test is then done at step 73 to determine if all
`servers have been accounted for during ihe compilation If
`not, the routine cycles hack If the outcome of the test at step
`73 is positive, however, the discovery process is complete
`In the preferred embodiment, the client runs Windows NT
`and the discovery mechanism is used tn discover non-native
`servers including, without limitatinn, SMB domains such as
`IBM Warp Scrvcr, IBM LAN Scrvcr, domains running on
`the AIX operating system, anil thc like. Altcrnativcly, the
`discovery mechanism is implemented in ihe nauve environ-
`ment and thus w used to iliscover other Windows NT
`domains. This latter implementation is especially advanta- es
`geous in Windows Nltbased client-server or other such
`"closed'* system because it
`reduces the time otherwise
`
`so
`
`needed to have, administrators imhvidually set up
`
`*'trust'elationships(as used between individual Wmdows NT
`
`scrvcr domains) or cquivalcnt relationships. Thus, in onc
`embodiment, thc discovery mechanism is implemented ata
`client running a native operating system and is used to
`discover native server domains In either case, preferably the
`ihscovery process olfers the administrator an associated
`"policy" mechamsm that enables the administrator to tailor
`how thc user at thc client may interact with thc discovcrcd
`authentication information.
`In particular, once thc list of scrvcr domains is discovcrcd,
`the administrator (i.c. during installation or configuration)
`may manage the list of nauve aml non-nauve server domains
`(as well as other functions) in order to control the user's
`authentication options. This is step 32 in the flowchart of
`I'IG 4, and this step preferably takes place at
`the client
`machine from which users will later seek tn be authenti-
`catctl. FIG. 7 illustrates this process in thc prcfcrrcd embodi-
`ment.
`In particular, at step 74, the onc or morc lists of scrvcr
`tlomains (which may bc just onc list with two parts) rlis-
`covcred are prcscntcd to thc administrator. Thc administra-
`tor is then prompted at step 76 to select the domains that will
`be presented to a given user seelong to be authenucated
`when a logon is initiated. Thus, step 76 enables the admin-
`istrator to remove particular authentication lncations from
`the sct of locations that can bc vicwcd by thc user on thc
`logon panel. If desired, the atlministrator may also cntcr thc
`name of an authentication location and have it prcscntcd to
`the user on the logon panel as an addiuonal authentication
`location. This operation is represented at step 78 in FIG. 7.
`the administrator may add a particular
`In this manner,
`authentication location of which he or she is aivare but that
`is not "discovcrcd*'uring thc discovery process for what-
`ever reason. At step 80, thc administrator is prompted to
`tlctcrminc ivhcthcr users of thc client machine arc to bc
`restricted from entering their own authenucauon locanons at
`that particular client machine. Step 8U thus determines
`whether users are to be limited to selecting one of the
`locations discovered and presented at the logon screen At
`step 82, thc administrator sckcts whcthcr users of thc client
`to cause a ncw
`machine are able to initiate a rcqucst
`thscovcry of authentication locations to bc cxccukd from
`the logon panel. This completes the management process.
`Thus, according to thc present invention, once authenti-
`cation locations arc discovcrcd,
`thcsc locations may bc
`managed for presentation to the users seeking authentication
`at the client. This information is preferably presented to the
`user via a logon display screen or panel with preferably three
`(3) or more fields a user name field, a password held, and
`a "front" dialog box in which thc user cntcrs t