soporte at sentinel.com.ar
Sat Apr 3 02:42:40 GMT 1999
>GINAs are not an appropriate place to provide alternative authentication.
>microsoft is fully aware of this and deliberately does not provide any
>information about the more appropriate API interface (the Local Security
>Authority) except if you pay them extortionate amounts of money and if
>they like the way that you smell.
>therefore, the only _public_ way to provide alternative authentication is
>to have a GINA that calls into MSGINA once you have "done your own thing"
>sufficient to fool MSGINA into thinking that the [Kerberos, NIS etc] user
GINA is more adecuate to change the "interface" of the login, i think.
if you want to change the method of authentication you should use a subauthentication
package, or an authentication package.
the default authentication package is msv1_0.dll, here is where all the code that compares the hash of your password with the local or remote sam database resides.
you can also write a subauthentication package that can do EXTRA authentication, and if that extra authentication fails, the logon is failed.
to write a new authentication package would be the rigth thing.
The LSA API is documented in LSAAUTH.HLP, i've being doing some research on this lately, do you know this documentation? it doesn't contain everything you need?
Microsoft has done some nasty tricks with this file. if you read the help file sequentially, you won't find the CRUCIAL sections where the LSA API is documented, they're missing. but if you go to the index, or do a search, you will see all that important parts that you were looking for.
yes, another one from microsoft, unbelievable.
i think there's everything you need, i didn't read the API too much because i didn't need it for what i was trying to accomplish, now that i remember, maybe it was too much oriented towards the MSV1_0 API, anyway, i have "researched" msv1_0.dll so if you need everything maybe i can help.
hochoa at core-sdi.com
More information about the samba-ntdom