Re: Scripting: How to tell if login was cached or domain?

2009-02-09 Thread Bill Monicher
If its cached the LogonServer environment variable is the local machine name.
If logged on via a DC, the LogonServer environment variable is the server name.
--BM

On Thu, Feb 5, 2009 at 9:04 AM, Stephen Wimberly  wrote:
> I have a script that I want to run, but only when the user login was cached.
> Is there a way to tell whether the current user login was cached or verified
> by a domain controller?
>
> I _thought_ I'd use the %logonserver% variable, but apparently it shows the
> domain controller that last authenticated the user even when the current
> login was cached.
>
> Most scripts I've seen ping a server that is only available on the LAN and
> look for the reply.  In this case though I don't care if they are on LAN or
> not, I care if they are cached or not.
>
>
> I found a script that looks through the event log for "Last cache login" and
> displays the date/time, but it doesn't effectively tell me what my current
> login is.
>
> Anyone know a way to tell?  I know the XP firewall has settings for a domain
> profile, is it using a domain profile for all cached logins?
>
> Thanks In Advance for pointers!
>
>
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~   ~
>

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~


RE: Scripting: How to tell if login was cached or domain?

2009-02-05 Thread Free, Bob
I'd think klist would be more like if that was the chosen route as it's
CLI



From: Devin Meade [mailto:devin.me...@gmail.com] 
Sent: Thursday, February 05, 2009 10:26 AM
To: NT System Admin Issues
Subject: Re: Scripting: How to tell if login was cached or domain?


kerbtray - I don't know if it can be scripted.  
 
hth Devin


On Thu, Feb 5, 2009 at 11:04 AM, Stephen Wimberly
 wrote:


I have a script that I want to run, but only when the user login
was cached.
Is there a way to tell whether the current user login was cached
or verified
by a domain controller?

I _thought_ I'd use the %logonserver% variable, but apparently
it shows the
domain controller that last authenticated the user even when the
current
login was cached.

Most scripts I've seen ping a server that is only available on
the LAN and
look for the reply.  In this case though I don't care if they
are on LAN or
not, I care if they are cached or not.


I found a script that looks through the event log for "Last
cache login" and
displays the date/time, but it doesn't effectively tell me what
my current
login is.

Anyone know a way to tell?  I know the XP firewall has settings
for a domain
profile, is it using a domain profile for all cached logins?

Thanks In Advance for pointers!



~ Finally, powerful endpoint security that ISN'T a resource hog!
~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~





-- 
Devin


 

 

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~



RE: Scripting: How to tell if login was cached or domain?

2009-02-05 Thread Troy Meyer
Pretty sure kerbtray cant be scripted since its interactive from the desktop.

Try using WMI and the Win32_LogonSession class.  It looks like there is a 
logontype property that will give you that info.

http://msdn.microsoft.com/en-us/library/aa394189(VS.85).aspx


-troy

-Original Message-
From: Devin Meade [mailto:devin.me...@gmail.com] 
Sent: Thursday, February 05, 2009 10:26 AM
To: NT System Admin Issues
Subject: Re: Scripting: How to tell if login was cached or domain?

kerbtray - I don't know if it can be scripted.  
 
hth Devin


On Thu, Feb 5, 2009 at 11:04 AM, Stephen Wimberly  
wrote:


I have a script that I want to run, but only when the user login was 
cached.
Is there a way to tell whether the current user login was cached or 
verified
by a domain controller?

I _thought_ I'd use the %logonserver% variable, but apparently it shows 
the
domain controller that last authenticated the user even when the current
login was cached.

Most scripts I've seen ping a server that is only available on the LAN 
and
look for the reply.  In this case though I don't care if they are on 
LAN or
not, I care if they are cached or not.


I found a script that looks through the event log for "Last cache 
login" and
displays the date/time, but it doesn't effectively tell me what my 
current
login is.

Anyone know a way to tell?  I know the XP firewall has settings for a 
domain
profile, is it using a domain profile for all cached logins?

Thanks In Advance for pointers!



~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~





-- 
Devin


 

 


~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/>  ~



Re: Scripting: How to tell if login was cached or domain?

2009-02-05 Thread Devin Meade
kerbtray - I don't know if it can be scripted.

hth Devin

On Thu, Feb 5, 2009 at 11:04 AM, Stephen Wimberly wrote:

> I have a script that I want to run, but only when the user login was
> cached.
> Is there a way to tell whether the current user login was cached or
> verified
> by a domain controller?
>
> I _thought_ I'd use the %logonserver% variable, but apparently it shows the
> domain controller that last authenticated the user even when the current
> login was cached.
>
> Most scripts I've seen ping a server that is only available on the LAN and
> look for the reply.  In this case though I don't care if they are on LAN or
> not, I care if they are cached or not.
>
>
> I found a script that looks through the event log for "Last cache login"
> and
> displays the date/time, but it doesn't effectively tell me what my current
> login is.
>
> Anyone know a way to tell?  I know the XP firewall has settings for a
> domain
> profile, is it using a domain profile for all cached logins?
>
> Thanks In Advance for pointers!
>
>
>
> ~ Finally, powerful endpoint security that ISN'T a resource hog! ~
> ~   ~
>



-- 
Devin

~ Finally, powerful endpoint security that ISN'T a resource hog! ~
~   ~