[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]


On Wed, 28 Oct 1998, Alan DeKok wrote:

> > actually what is needed is an NT Local Security Authority which does
> > RADIUS.  adding authentication into GINAs is a really bad hack, but
> > sadly microsoft do not see us fit to share knowledge of the LSA API
>   I know... what do you do when GINA goes to a remote server to
> authenticate you, but still need a password (?) to get UID/etc from
> the LSA?

ok.  deep breath.

the "lsa" is responsible for redirecting authentication of the user in a
similar way to what PAM does.  the SAM database implementation of an LSA
returns a set of user credentials:

- username (*can* be different from login name bu nt doesn't do this)
- user's RID in the domain (domain sid plus user's rid is equiv to uid)
- user's primary group RID (equiv. to gid in same way as above)
- list of other groups
- profile location
- home dir
- logon hours
- etc.

this is all done behind the scenes of a "LsaLogonUserEx" API-level
function, which is undocumented.  the _documented_ version is called
"LsaLogonUser". no, it doesn't work properly in the same way that
LsaLogonUserEx does.

so how do hacked-ginas work?

in the GINA, you are handed the username, passsword and domain name in
clear-text.  you authenticate against your whatever-server, and then if
correctly validated, you:

- create a LOCAL account on-the-fly on the LOCAL workstation (which has
its own SAM database for this purpose, and its own SID), which means that
you will be allocated an arbitrary RID for use on the workstation you are
logging in to (the APIs give you no choice over what RID to create).

the implications of this are that any files created on the local
workstation will be inaccessible or worse, accessed with incorrect file
permissions, to anyone attempting to read that file: _even_ the same user
who logs in on two workstations simultaneously, because they will be, to
all intents and purposes, different users (with totally different SID-RID

- call, through some mechanism i do not understand, the MSGINA.DLL version
of the GINA-logon function that the OS has just called in _your_ GINA dll.


so that the setup of the workstation, which includes setting up profiles
etc, can go ahead.  and given that you have just created an account for
the user (see above), this will succeed.

basically, the more GINAs there are out there that circumvent microsoft's
policy of forcing people to use NT servers for authentication, the better.
then they might do one of two things:

- release documentation on how to do the job properly
- remove documentation on GINAs, and change the API.

> > that having been said,a there is a PAM port to NT which uses [the bad
> > hack of] GINAs.  a talk on it was given at the lisa-nt98 conference
> > (start at http://www.usenix.org, sorry i don't have reference to
> > hand).
>   I found the authors home page at:
> http://www-personal2.engin.umich.edu/~itoi/

nice one.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []