Vista - Log in to server using current username/pwd

Hi,

In our former domain based system we used the subroutine below to map
network drives to local drive letters. Since the clients already were
logged on to the domain, the server never needed to request explicit
authentication.

However when using Home Edition clients the server obviously requests
username and password when clients want to access these drives.

But luckily in this case the username and password expected by the
server are the same as those the local user used to log on to the computer.

Could the sub below be modified to supply or copy the current local
username and password to the server while mapping the drive so the local
user is not requested to re-authenticate?

Thanks for comments on this

regards jake

Sub MapMyDrives(strDriveLetter, strPath, strDescription)
'Remove former login's drive letters
'Map drive to new letter...
'Set friendly name
If fso.driveexists(strDriveLetter) Then
nwo.RemoveNetworkDrive strDriveLetter, True, True
wscript.sleep 300
End If
nwo.MapNetworkDrive strDriveLetter, strPath
sao.NameSpace(strDriveLetter).Self.Name = strDescription
End Sub

Il giorno Thu, 13 Aug 2009 13:39:42 +0200, Jake <jake44@xxxxxx> ha scritto:AFAIK, you can get the name of the current user, but not his password.

--
Giovanni Cenati (Bergamo, Italy)
Write to "Reventlov" at katamail com
http://digilander.libero.it/Cenati (Esempi e programmi in VbScript)
--

"Jake" <jake44@xxxxxx> wrote in message
news:OXF8ArAHKHA.4024@xxxxxxAs Reventlov said, you cannot extract passwords. If you could then this
would be a gross breach of password security. You could create domain
accounts/passwords that are identical to local accounts/passwords. This
would get around the password prompt but it would create a nightmare when
your users change their passwords.

In a domain environment you should use WinXP Professional clients. Using
WinXP Home clients is unproductive.

Pegasus [MVP] wrote:
Of course I know that, but I would just check if there was a way for
windows to secretly forwarding the current user's auth data without
revealing the password openly.
OK, great, so matching usernames / passwords for a domain account will
allow a workgroup computer to use resources on the server. That would
be fine, because the users are not allowed to change their passwords
(which are kept synced with their LMS software).
Of course, if you go and convince Bill that he should allow selling
netbooks with XP Pro preinstalled that would definitely be our first
choice, but apparently Microsoft doesn't allow that.

regards

jake

"Jake" <jake44@xxxxxx> wrote in message
news:#7YUyFLHKHA.3000@xxxxxxI do not think that that is possible. Windows does not walk around with a
copy of your password in its back pocket - basically, it does not know what
your password is. When you logon, the password is not compared with the one
stored in the SAM database, because the password is not stored there. A
one-way hash of the password is stored that is based, in part, on the date
when the password was last changed. When you enter your password at logon,
what you enter is hashed in the same way and the result compared with the
stored value. If they are the same then you just logged on with your
currently valid password, which is promptly forgotten (i.e. obliterated from
memory or anywhere else where it might otherwise hang around).

We all think of other humans as being the entities that will use our
credentials without our permission. But software, including the O/S, is also
a potential threat. I'm not saying that Windows itself wants to abuse our
credentials, just that, if it knew the password, it is concerned that
someone might find a way to extract it.

Of course, one way to accomplish what you want is to logon using a computer
that is a member of the domain and a domain account. In that circumstance, a
token is created for the session that encapsulates your group membership.
The file system, for example, uses this token to determine your access
rights instead of processing your group membership each time you try to
access a resource.
Personally, I don't find that a very manageable solution, even if passwords
cannot change...
I haven't looked into that, but have you looked into the possibility of an
upgrade license?

/Al

"Al Dunbar" <alandrub@xxxxxx> wrote:Go inform yourself about credential reflection/playback!
MSFT published another patch for such a problem just this tuesday.-(

Stefan

"Stefan Kanthak" <postmaster@[127.0.0.1]> wrote in message
news:uV0eZIdHKHA.1248@xxxxxxThanks for the hint.

While I have not yet fully understood the mechanism, in the context of this
thread the effect is the same as if no such vulnerability existed. If one
actually *could* figure out how to leverage this "feature" to get windows
"to secretly forward the current user's auth data..." for some valid
purpose, the method would stop working as soon as the countervailing patch
was released.

I will rephrase what I said above: "Windows should not be walking around
with a copy of your password in its back pocket".

If Windows does not provide a capability to do what the OP wants, leveraging
a vulnerability to accomplish this does not seem a sensible approach.


All that said, I do not see where "using the victim's credentials" means
that the actual password was revealed, which would imply that Windows did
keep a copy in its back pocket. Lots of attacks use the victim's credentials
without ever finding out what the password is.


/Al

"Al Dunbar" <alandrub@xxxxxx> wrote:De nada.
Actually it's NO vulnerability, it's just "sending out the current user's
authentification".
Since the beginning of DOS' (and Windows') networking the user logs on to
the client which caches the authentication. When the client connects to
"the network" this cached authentication is sent to the target (nowadays
after negotiation of the authentication protocol to use it's most often
a challenge-response proof that the client has the right authentification)
without further notice to the user! If the target but requests cleartext
authentication and the client accepts that then username/password may be
transmitted in clear!

As practical example use the Internet Explorer in your intranet where it
uses the current windows user login to authenticate to web servers. Now
setup your own web server and request basic auth...
But it does! Yes, you can configure it to never send cleartext (or near
cleartext, i.e. replayable) authentication data, but have you done so?
It doesn't matter whether you have the real password or derived credentials
when you can use these credentials to authenticate.

Stefan

"Stefan Kanthak" <postmaster@[127.0.0.1]> wrote in message
news:#ElD2gnHKHA.4376@xxxxxxPerfectly OK, imho, as I assume that the "cached authentication" cannot
generally be used outside of the context of the user session that cached the
authentication...
May, or will? I had thought that the cached authentication did not include a
copy of the text of the password. Do you have a reference to where it is
explained that it does?
Not sure, as the client configuration at work is not something I can change.
I agree. So why have you not answered the OP's question about how to
actually do this: "Of course I know that, but I would just check if there
was a way for windows to secretly forwarding the current user's auth data
without revealing the password openly."

/Al

Maybe common sense does not prevail here. But doesn't the password (even if
its is encrypted) have to be stored on the machine somewhere? Isn't that
the only way a match can be made? How else can it make a match to what you
input?


"Al Dunbar" <alandrub@xxxxxx> wrote in message
news:OBH8xMpHKHA.4168@xxxxxx