locked
How to test if user authenticated with cached credentials RRS feed

  • Question

  • I would like to gently remind users who have logged in with cached credentials for X days that they should bring their machine back and connect it to the network for a boot or two, and I'd like to push the structure out through GPO.  There is significant interest (and no answers) in expiring cached credentials after some time, but I dont' want to prevent users from working, just request/annoy them to come "home" once in a while.

    I have found mention that comparing %logonserver% with %computername% as a valid way to check for cached login, but these are old (~2003).  When I do that in Win7 while booted and logged in via cached credentials, my %logonserver% is the PDC of the user account's domain.  (The computer account is in a subordinate domain.)  Why would the system report a %logonserver% that is unreachable?  Has something changed in how this works?

    What appears fairly foolproof (when done manually) is to monitor the Security Log for EventID 4624 with Login Type 11.  I can trigger a scheduled task on the EventID, but I don't know how to filter for Login Type.  I also don't think the scheduled task can work in the user's security context because the Security Log requires elevation or at least admin rights.  Is this true?  Additionally, I haven't a clue how to establish a scheduled task via GPO/script especially one that would run under local admin creds (with each laptop having a unique password). 

    I can't believe something that seems so common sense is so challenging that it hasn't been solved yet.

    Thursday, May 17, 2012 1:48 PM

Answers

  • I generally agree with Bill and JR.

    Who places the expectation on you that the computers should be maintained in a relatively up to date state? If this is only you, don't bother. If someone else, then explain the requirement that computers be brought in periodically, and explain that there is no technological solution that will get the users to follow policy. Then leave it up to the policy makers to solve the problem.


    Al Dunbar

    • Marked as answer by Bill_Stewart Thursday, May 31, 2012 7:41 PM
    Wednesday, May 23, 2012 4:18 PM

All replies

  • Hi,

    Have you considered looking at users' lastLogonTimestamp attribute?

    Bill

    Thursday, May 17, 2012 3:41 PM
  • As I understand it, that is part of the user account stored on the DC.  If users are logging onto a laptopthat can't see the domain (or any network even) using cached credentials, how would this help?  If they didn't also have a regularly used desktop machine in the office, I suppose a server could send them email, but I am looking for something local to the computer they are using their cached credentials on.  

    Is the lastLoginTimestamp attribute held on the local machine somehow? 

    Thanks.

    Thursday, May 17, 2012 4:56 PM
  • Hi,

    Are you looking for a way to identify stale computer accounts? The oldcmp.exe utility can help you do that.

    Bill

    Thursday, May 17, 2012 5:02 PM
  • I would like to gently remind users who have logged in with cached credentials for X days that they should bring their machine back and connect it to the network for a boot or two, and I'd like to push the structure out through GPO.  There is significant interest (and no answers) in expiring cached credentials after some time, but I dont' want to prevent users from working, just request/annoy them to come "home" once in a while.

    I have found mention that comparing %logonserver% with %computername% as a valid way to check for cached login, but these are old (~2003).  When I do that in Win7 while booted and logged in via cached credentials, my %logonserver% is the PDC of the user account's domain.  (The computer account is in a subordinate domain.)  Why would the system report a %logonserver% that is unreachable?  Has something changed in how this works?

    What appears fairly foolproof (when done manually) is to monitor the Security Log for EventID 4624 with Login Type 11.  I can trigger a scheduled task on the EventID, but I don't know how to filter for Login Type.  I also don't think the scheduled task can work in the user's security context because the Security Log requires elevation or at least admin rights.  Is this true?  Additionally, I haven't a clue how to establish a scheduled task via GPO/script especially one that would run under local admin creds (with each laptop having a unique password). 

    I can't believe something that seems so common sense is so challenging that it hasn't been solved yet.

    Have you looked at teh eventlog entry to see when the last full logon occurred?  This would be what you are looking for.

    You caoulds also just set a registry value to the login time from a login script then check that uisng a scheduled task.  If it has not changed for n days and teh domain is not conencted you could display a message.

    YOU can also just set teh length of time for the computer account to see the domain to a bigger number.  I think it is set at 14 days for laptops.


    ¯\_(ツ)_/¯

    Thursday, May 17, 2012 5:30 PM
  • Hi,

    No.  I want to identify (and notify) users who are logging into machines for an extended period (90+ days) under cached credentials.  I am not interested in stale user or computer accounts in AD.

    Thanks.

    Friday, May 18, 2012 5:43 PM
  • Have you looked at teh eventlog entry to see when the last full logon occurred?  This would be what you are looking for.

    You caoulds also just set a registry value to the login time from a login script then check that uisng a scheduled task.  If it has not changed for n days and teh domain is not conencted you could display a message.

    YOU can also just set teh length of time for the computer account to see the domain to a bigger number.  I think it is set at 14 days for laptops.

    If you mean by "full logon" that someone isn't just unlocking/waking the machine, then no because we have users who will dutifully shutdown before closing the lid, but will go several years (!) before bringing the machine back to connect and update with the domain.

    I don't understand what the "length of time for the computer account to see the domain" means. 

    Thanks.

    Friday, May 18, 2012 5:49 PM
  • Hi,

    Can you define specifically what you mean by "connect and update with the domain"? What specifically is the problem you're trying to solve? (Describe the goal, not the steps.)

    Bill

    Friday, May 18, 2012 6:51 PM
  • You will need to place some kind of timestamp in the regsitry when the user log into the domain.  After that just check registry to see if teh login is with cached credential.  If it is then check the timestamp against todays date to see how long it has been.

    You can put the timestamp in the regstry in a doing login script.  YOu can use a local login script to check the registry and eventlog.


    ¯\_(ツ)_/¯

    Friday, May 18, 2012 7:00 PM
  • Machines that are away for long periods of time do not get updated GPOs, startup scripts, distributed software, inventory logs, etc..  If we can convince our users to bring them back to the local network once in a while (and reboot them would be nice), much of that can be resolved. 
    Friday, May 18, 2012 8:41 PM
  • "to see if teh[sic] login is with cached credential" is exactly what I want to do.  Are you saying to compare the time stamp with the current time?  What if it's been days (or weeks, or -- ugh -- months) since someone logged in?  Determining if a user has logged into the domain would be just as useful for me.  They are effectlively the same question... What kind of login did the current user utilize? 

    Friday, May 18, 2012 8:44 PM
  • Hi,

    So their computers don't get connected to the network for a long time and they have some stale distributed software. Isn't it the user's responsibility to bring in said computers and log onto the network according to some policy? I would disable stale computer accounts after some period of time. In this way they will have to get their computer account reset if they come in and can't log on. You could also enforce password expiration.

    I guess I don't see why you need the specific information you're asking for - there are other ways to handle users that don't connect if you need to enforce policies on their computers. I would think there would need to be an IT policy of some kind in place.

    Bill

    Friday, May 18, 2012 9:39 PM
  • I think you were close to a solution in your initial post. Try something like this:

        if "%logonserver%" EQU "%computername%" (
            (set logontype=cached)
        ) else (
            if not exist "%logonserver%\netlogon" (
                (set logontype=cached)
            ) else (
                (set logontype=noncached)
            )
        )
        echo/logon type: %logontype%


    should your script determine that the user has not had a noncached logon on this computer in the last X days or more, it could display some message to that effect. The weakness of this approach is that the user needs to logon to his computer before he gets this notification.

    We found in the past that some laptops used for remote access were not actually turned on for months or years while the users themselves were logging in regularly on other computers in the office.

    We took a different approach and had our logon script record the date, time, username, computername, and logonserver name of each logon to a series of csv files in a hidden share on a server. We could then find the last time one of the remote systems logged in directly by combiming the csv files and filtering on the computername. We then determine the type of logon based on the logonserver value (xp clients only so far), as a completely different set of DC's is ever used for remote authentication.

    Once we determine it has been long enough, we then send the user an email reminder - which he will get in the office even if he never logs on remotely.


    Al Dunbar

    Friday, May 18, 2012 9:42 PM
  • Hi,

    So their computers don't get connected to the network for a long time and they have some stale distributed software. Isn't it the user's responsibility to bring in said computers and log onto the network according to some policy? I would disable stale computer accounts after some period of time. In this way they will have to get their computer account reset if they come in and can't log on. You could also enforce password expiration.

    I guess I don't see why you need the specific information you're asking for - there are other ways to handle users that don't connect if you need to enforce policies on their computers. I would think there would need to be an IT policy of some kind in place.

    Bill

    Ha, we tried that. It turns out that if you are logging on to a disconnected machine with cached credentials, the machine cannot be aware that the machine account has been disabled because it is not yet connected to the AD network at this point. Then when you establish a VPN connection, the machine still does not attempt to logon to the network, so you get in from a disabled system.

    I agree it is the user's responsibility to ensure their machines are kept reasonably up to date. What the OP is trying to do is find a way to let them know it is time to do so. They are probably not IT techs, so assume that if the computer is still working all is OK.


    Al Dunbar

    Monday, May 21, 2012 1:47 AM
  • Have you seen SYNERGIX AD Client Extensions ?  It may be worth exploring some features in this product.

    http://www.synergix.com/products/active-directory-client-extensions/screenshots/

    See the second screenshot in that link i.e.

    Password Expiration

    Even if the user has not connected for several weeks / months, they will still get prompted for Domain User Account Password Expiration Notification.   There is clear notification displayed to them to login and reset their user account password ( next screenshot ).  Then the trigger ( corporate network connectivity via VPN ) with which they can change their domain credentials and immediately synchronize the cached credentials, will also take care of group policy updates, computer account trust reset with domain ( default 30 days ), Kerberos Ticket refreshes and many other annoying issue that surround users working from remote offices and in an unpredictable time manner.

    Password Change

    Lastly,  here's a Youtube video  http://www.youtube.com/watch?v=_1pae5MDBxg 

    I hope this information sheds some light and helps you think about some solutions, home grown or 3rd party like from Synergix that you can deploy to put closure on such issues

    If, like mine, the OP's users are coming in to the office to logon to desktop computers directly connected to the network, while they leave their remote machine at home, the Synergix solution would not serve the OP's stated purpose.


    Al Dunbar

    Monday, May 21, 2012 1:50 AM
  • Thanks for the suggestion, but I could figure out the code if %logonserver% ever was = %computername%.  The only time that is true from my testing is if the account is local.  Domain accounts logging in with cached credentials both in Win7 and WinXP have the PDC as the %logonserver%.  I can't just test for that because that could be true any time (offline or not).

    That's the entire crux of my question.  How can a user tell if they are logged in with cached credentials?

    Monday, May 21, 2012 12:33 PM
  • My users are like yours.  Why won't the Synergix solution work?  I'm guessing it's because the computer-side GPOs won't be rolled in, and likely distributed software won't get pushed out.
    Monday, May 21, 2012 12:40 PM
  • Thanks for the suggestion, but I could figure out the code if %logonserver% ever was = %computername%.  The only time that is true from my testing is if the account is local.  Domain accounts logging in with cached credentials both in Win7 and WinXP have the PDC as the %logonserver%.  I can't just test for that because that could be true any time (offline or not).

    That's the entire crux of my question.  How can a user tell if they are logged in with cached credentials?

    YOU can check the eventlog to see if teh last logon was with cached credentials.  YOu coulds also just try and ping the domain controller.

    If you place a timetstamp in teh registry when logging onlt the domain then check it periodically - one a day.  It will tell you how long it has been since the laptop has seen a DC.  This will accomplish the exact same thing.

    Crete one script to create a scgedulted task.  Have that script create the first registry entry then gave it schedule the check once a day.  The script can run in the context of the user.

    Add a line to your logon scripts in teh doamin that sets teh time in the users regesitry when they logon to the domian.  Every time the user log into teh domain the timestamp gets reset.  If they have no logged in for the decided period the script on the workstation can notify them that they have to log in.

    This is not a difficult thng.  The hard part is getting all of the susers to come back and login after you have this set up.

    One of the scritp would be more than a few lines.  No need for an expensive solution which will just do the same thing with a fancy GUI.


    ¯\_(ツ)_/¯

    Monday, May 21, 2012 2:22 PM
  • It sounds to me more like a human resource problem rather than a technical problem. Who owns the computer? Is there an organizational policy in place that states users need to comply with this request? What consequences are there for users that do not comply?

    Bill

    Monday, May 21, 2012 2:55 PM
  • If this were not a University, I think it could be handled at the HR/Management level.  Being a University, except in cases involving legal requirements, policy is largely toothless and treated more as guidelines.  Short of a physical altercation or gross theft, anyone here long enough (and hence, set in their ways) ain't getting fired.  It is truely like hearding cats.  If we can annoy them enough they might comply.
    Monday, May 21, 2012 8:16 PM
  • Again, how does a user script tell from the event log if the last logon was with cached credentials? 

    You keep saying this is all I need to do, but that is the part that I am asking how to do.  It seems nobody else knows how to do this either.  If you have figured it out, please share!

    Monday, May 21, 2012 8:20 PM
  • We don't expire user passwords.

    Monday, May 21, 2012 8:24 PM
  • Hi,

    Two questions:

    1. Why does the computer need to be reconnected to its home domain if the computer's user can work without problems without connecting to the domain?
    2. If a computer stays disconnected from the domain, why is it a member of the domain?

    Bill

    Monday, May 21, 2012 8:37 PM
  • Again, how does a user script tell from the event log if the last logon was with cached credentials? 

    You keep saying this is all I need to do, but that is the part that I am asking how to do.  It seems nobody else knows how to do this either.  If you have figured it out, please share!

    I am surprised that you didn't jsut log in with cached credentials and look.

    It is logon type 11.

    Here is a nice table:

    Logon Type

    Description

    2

    Interactive (logon at keyboard and screen of system) Windows 2000 records Terminal Services logon as this type rather than Type 10.

     

    3

    Network (i.e. connection to shared folder on this computer from elsewhere on network or IIS logon - Never logged by 528 on W2k and forward. See event 540)

     

    4

    Batch (i.e. scheduled task)

     

    5

    Service (Service startup)

     

    7

    Unlock (i.e. unnattended workstation with password protected screen saver)

     

    8

    NetworkCleartext (Logon with credentials sent in the clear text. Most often indicates a logon to IIS with "basic authentication")

     

    9

    NewCredentials

     

    10

    RemoteInteractive (Terminal Services, Remote Desktop or Remote Assistance)

     

    11

    CachedInteractive (logon with cached domain credentials such as when logging on to a laptop when away from the network)

     


    ¯\_(ツ)_/¯



    • Edited by jrv Monday, May 21, 2012 9:57 PM
    Monday, May 21, 2012 9:50 PM
  • OK.  if can run a script via gpo or other means, simply ping the domain and find the results ex 'ping request could not find ....'.  and when you get 'reply from ....', you can send output to a file and check date / time stamp on it to determine last time it connected to the domain.  simple logic but you can probably enhance further with vbscript or powershell.

    ... still thinking what else can be done

    Dabrabdarra cadabra bra

    Hey - This is a thread by Cascomp.  You are adding confusion.

    You need to understand how GPO works.  It will only be applied when connected to teh domain.  When the GPO execute the login it updates the timestamp.  The scheduler then just checks the difference betwenn the registry and the current date.

    This has absolutely nothing to do with passwords.  It just says how long hasz itr been since we last logged into teh domain successfully.

    Two short 5 line scripts.  That is all.


    ¯\_(ツ)_/¯

    Monday, May 21, 2012 10:01 PM
  • My users are like yours.  Why won't the Synergix solution work?  I'm guessing it's because the computer-side GPOs won't be rolled in, and likely distributed software won't get pushed out.

    I didn't say that wouldn't work, just that I do not think it would serve your purpose. It all seems to hinge on advising the user when his password is about to expire. You do not expire passwords, but even if you did (as we do), the users would likely change their passwords when they come in to work on a directly connected desktop in the office. The date of expiration of the user password has exactly no relationship to how long they have been logging on with cached passwords.

    Al Dunbar

    Monday, May 21, 2012 11:10 PM
  • Hello Cascomp:

    with that adce software, the computer side GPO will also apply after the user has established connection to corporate network via VPN / wifi; basically it is deferred until the network connection to a DC is detected. so, you don't miss out on gpo assigned computer startup scripts, gpo assigned user logon script and interestingly a vpn connection / disconnection.

    I was thinking out loud a little bit and wondering if you *User* Password Expiration notification would also include the *Computer* Password Expiration as in the previous screenshot and if the administrator would consider aligning the computer password reset ( default 30 days ) to whatever the default password policy is applied to user account ( generally 60 to 90 days ). Certainly there are some security implication in extending the computer password change default but in all practicality, it should be finei ; in fact it should reduce replication ( due to computer password changes ) by few bits in a very large environment.

    With those two password expiration notifications lined up and with user and computer password expiration notification in place, it would basically address the 'call home' issue.

    if the software enables GPO actions when a VPN connection is established, that might be useful. Of course, it depends on what mechanism(s) the OP's company uses to apply updates. If it is all GPO based, that might allow for the remote systems to be fully updated without their having to be brought in to be physically connected. Of course, there are other benefits to that practice in the area of asset management...

    But if the users routinely either work on their computers without connecting, the user still needs something to remind them that they should connect.


    Al Dunbar

    Monday, May 21, 2012 11:19 PM
  • Thanks for the suggestion, but I could figure out the code if %logonserver% ever was = %computername%.  The only time that is true from my testing is if the account is local.  Domain accounts logging in with cached credentials both in Win7 and WinXP have the PDC as the %logonserver%.  I can't just test for that because that could be true any time (offline or not).

    That's the entire crux of my question.  How can a user tell if they are logged in with cached credentials?


    if %logonserver% is always set to the PDC even when logging on with cached credentials, then you could deduce a cached credential logon if %logonserver% does not respond to a ping or if the netlogon share is not accessible. As long as the test is done before the creation of a VPN connection.

    Al Dunbar

    Tuesday, May 22, 2012 2:01 AM
  • Hi,

    Two questions:

    1. Why does the computer need to be reconnected to its home domain if the computer's user can work without problems without connecting to the domain?
    2. If a computer stays disconnected from the domain, why is it a member of the domain?

    Bill


    In our situation, the computers we use for remote access are domain members (question 2) because their custodians will sometimes visit other sites where they can just plug in to the network (we do not currently alow wifi hotspots in our facilities). In answer to question 1, some of the updates we push out are more successful when the client is directly connected.

    Al Dunbar

    Tuesday, May 22, 2012 2:05 AM
  • If this were not a University, I think it could be handled at the HR/Management level.  Being a University, except in cases involving legal requirements, policy is largely toothless and treated more as guidelines.  Short of a physical altercation or gross theft, anyone here long enough (and hence, set in their ways) ain't getting fired.  It is truely like hearding cats.  If we can annoy them enough they might comply.

    I understand your situation. You should try to find ways in which the annoyances relate to natural consequences rather than something the IT support staff likes to do to the users.

    Al Dunbar

    Tuesday, May 22, 2012 2:09 AM
  • Yep, I know all about the logon type (and there are also the rarely seen types 12 and 13).  I have figured out how to make an event filter in XPath form now for just the Logon Type 11:

    <QueryList>
      <Query Id="0" Path="Security">
        <Select Path="Security">
    	*[System[
    		(Level=4 or Level=0 or Level=5) and 
    		(EventID=4624 or EventID=528)
    	]] and 
    	*[EventData[
    		(Data[@Name='LogonType']) and 
    		(Data='11')
    	]]
        </Select>
      </Query>
    </QueryList>

    The problem is that viewing the security log requires both admin rights and elevation.  How can a user script scan the security log?

    Tuesday, May 22, 2012 2:05 PM
  • This is a possibility.  Ideally, this check would occur immediately following login and/or unlock.  Login scripts won't run if the DC isn't seen, so what can I trigger this on (in scheduled tasks) related to user authentication?  I don't seem to be able to create a scheduled task triggered on events in the security log.  Should I just make it periodic?

    Thanks for all your comments.

    Tuesday, May 22, 2012 2:16 PM
  • In our situation, the computers we use for remote access are domain members (question 2) because their custodians will sometimes visit other sites where they can just plug in to the network (we do not currently alow wifi hotspots in our facilities). In answer to question 1, some of the updates we push out are more successful when the client is directly connected.

    Why not simply check for and disable stale computer accounts? In this case they won't be able to log on when they finally connect (natural, annoying consequence), and in this case the organization can say to the user: "To avoid this situation in the future, please connect the computer to the network at least once every x days."

    Bill

    Tuesday, May 22, 2012 2:16 PM
  • Yep, I know all about the logon type (and there are also the rarely seen types 12 and 13).  I have figured out how to make an event filter in XPath form now for just the Logon Type 11:

    <QueryList>
      <Query Id="0" Path="Security">
        <Select Path="Security">
    	*[System[
    		(Level=4 or Level=0 or Level=5) and 
    		(EventID=4624 or EventID=528)
    	]] and 
    	*[EventData[
    		(Data[@Name='LogonType']) and 
    		(Data='11')
    	]]
        </Select>
      </Query>
    </QueryList>

    The problem is that viewing the security log requires both admin rights and elevation.  How can a user script scan the security log?

    Just add an event to the security log that runs a script to check the user.

    I recommended using the prevoipus method where you place a timestamp in the registry.  Any user can do this and it does not require reading teh event log.

    YOu are making this way harder than it needs to be.  YOu have to choose a method and solve its problems.

    The best minds her keep sayin that you are going about this the wrong way.  YOu should probably listen to them.


    ¯\_(ツ)_/¯

    Tuesday, May 22, 2012 2:35 PM
  • I don't know how to "Just add an event to the security log that runs a script to check the user".  I'm not even sure what this means.  A log tracks events, it doesn't generate them.

    I've been planning to put a timestamp in the registry, but I need to know when that needs to be done. 

    I'd love to know of a simpler way to make this!  I haven't seen any workable solutions from you yet either.

    The best minds here are asking why I can't do "X" and I've been answering why.

    Even if there is a better way to get the result that I want in this case, the question of how a user (unpriviledged) determines if they have logged in with cached credentials remains totally unanswered.

    Tuesday, May 22, 2012 3:43 PM
  • Hi cascomp,

    I still don't understand the "why" of what you want to do. If the users don't want to connect a remote machine to the network, you can't force them to do so. It seems to me that displaying a reminder message is only going to be an annoyance they're going to ignore, provided they understand it in the first place. The computer is not connected to the network, so it's outside of your management scope. If the computer never connects to the network, why have it be a domain member at all, since it won't be managed?

    If you disable stale computer accounts, then users will have to consult IT to rejoin the computer to the domain in case they want to connect it again. This would be a natural consequence of not following the guidelines.

    Bill

    Tuesday, May 22, 2012 3:51 PM
  • Hi cascomp,

    I still don't understand the "why" of what you want to do. If the users don't want to connect a remote machine to the network, you can't force them to do so. It seems to me that displaying a reminder message is only going to be an annoyance they're going to ignore, provided they understand it in the first place. The computer is not connected to the network, so it's outside of your management scope. If the computer never connects to the network, why have it be a domain member at all, since it won't be managed?

    If you disable stale computer accounts, then users will have to consult IT to rejoin the computer to the domain in case they want to connect it again. This would be a natural consequence of not following the guidelines.

    Bill

    I appreciate your question. I think a lot of the answer is that things that seem reasonable in "the real world" are a major challenge to implement in a higher ed environment (at least this one).  Most faculty aren't trying to avoid bringing in a machine, they just forget that they haven't done so.  If we can remind/annoy them, many of them will bring it in.

    The machines are on the domain because we never know if a machine will be in every day or never return and in many cases, neither do the users.  In addition, that can change every few months and remain changed for a year or more.  Obviously, if they are on the domain and present on the network, we can offer all the nice management that a computer on the domain gets. 

    The problem with expiring computer accounts is that we would see a few common scenarios: 

    1) Users would choose to never bring the machine back for fear of losing access.  When they did, they would want to schedule a technician whether they needed one or not just in case.

    2) Users would repeatedly bring in computers with disabled AD accounts for critical work (teaching) that they then couldn't use and then scream up the chain to have the policy changed (which it would).

    You have to realize that the act of getting a Ph.D. makes many of these people wacky.  They may be a world renowned expert on X but can't understand that a local account (on a machine not in the domain) is different from an AD account with credentials that work in many places.  (Which is why we want the machines on the domain.)

    Tuesday, May 22, 2012 5:58 PM
  • Well, I have worked in environments similar to this (not education, but scientists, engineers, and medical professionals). I've found if you get buy-in from the stakeholders you can establish sensible guidelines for standard operations. I do understand that this can be logistically complicated depending on your environment.

    Bill

    Tuesday, May 22, 2012 6:10 PM
  • This is a possibility.  Ideally, this check would occur immediately following login and/or unlock.  Login scripts won't run if the DC isn't seen, so what can I trigger this on (in scheduled tasks) related to user authentication?  I don't seem to be able to create a scheduled task triggered on events in the security log.  Should I just make it periodic?

    Thanks for all your comments.

    Too many options, getting dizzy... ;-)

    I guess this depends on what you want to have happen. If you want the message to be presented when they logon with cached credentials, you could just run a script from startup in the all users profile. I'm not sure how one goes about detecting the transition from locked to unlocked, or how one could use that to start a script - but it probably can be done somehow.

    You could run it as a scheduled task, but then you might want to avoid popping the message up too often, so the script would need to keep track of when it last did so.

    As an aside, do your users have local admin rights on their workstations? If so, then, technically, they could disable any script you would setup to give them friendly reminders. Also, as admins, they then share the responsbility of managing their workstation effectively. For those who seem to bring their systems in too infrequently, I'd suggest taking away their admin rights (another thing needing buy-in).

    I agree 100% with Bill when he says that getting the buy-in from stakeholders is likely where you should start. If your job is to maintain the infrastructure and user action (or lack thereof) is interfering, this should be made clear. I think you have already gone overboard in trying to accommodate incidentally uncooperated users. I'd suggest you just send out periodic emails reminding users to bring their computer in to be updated. If you just logged whenever this happened (assuming there was some reason they needed to have IT look at it and not just connect it to the network for a while) then you would have a record of how long it has been since each computer was updated, and you could email specific reminders.


    Al Dunbar

    Tuesday, May 22, 2012 7:42 PM
  • In our situation, the computers we use for remote access are domain members (question 2) because their custodians will sometimes visit other sites where they can just plug in to the network (we do not currently alow wifi hotspots in our facilities). In answer to question 1, some of the updates we push out are more successful when the client is directly connected.

    Why not simply check for and disable stale computer accounts? In this case they won't be able to log on when they finally connect (natural, annoying consequence), and in this case the organization can say to the user: "To avoid this situation in the future, please connect the computer to the network at least once every x days."

    Bill


    In general I like the idea, but... having their computer accounts disabled will not prevent their logging in remotely, in which case we would still prefer that they be updated. Unfortunately, having them unable to give a presentation at a site thousands of miles from their home site in a different timezone when that was the sole purpose of their travel will not endear us at all to those involved. Fortunately for me, I am not currently working in desktop support, so it is no longer my issue ;-)

    Al Dunbar

    Tuesday, May 22, 2012 7:52 PM
  • I want to say thanks for all the suggestions.

    I will work on non-technical solutions to getting machines back "home" on a regular basis.

    I'm still disappointed that it appears that a user can't really know if they logged in with cached credentials or not.  That seems like an odd thing to restrict on purpose and an oversight if not by design. 

    Tuesday, May 22, 2012 8:13 PM
  • Sorry, I don't think there's a really good answer for your question that doesn't involve some kind of hack that runs code on the computer in question. This is especially problematic if, as Al Dunbar pointed out, end-users are members of the local Administrators groups on their local machines, as they can simply disable your notification mechanism.

    Bill

    Tuesday, May 22, 2012 9:14 PM
  • The problem with expiring computer accounts is that we would see a few common scenarios: 

    1) Users would choose to never bring the machine back for fear of losing access.  When they did, they would want to schedule a technician whether they needed one or not just in case.

    2) Users would repeatedly bring in computers with disabled AD accounts for critical work (teaching) that they then couldn't use and then scream up the chain to have the policy changed (which it would).

    You have to realize that the act of getting a Ph.D. makes many of these people wacky.  They may be a world renowned expert on X but can't understand that a local account (on a machine not in the domain) is different from an AD account with credentials that work in many places.  (Which is why we want the machines on the domain.)

    Your logic is somewhat convoluted and tends to argue that you are right because of factors that cannot be controlled.  If that is the case then you should just not bother as you have already proven that the cats cannot be herded.

    OR -

    You could just do what I posted above and tag the machine each time it sees the domin then run a task every day that checks the time stamp against the current date. 

    Simple.  You should be able to code that in a few minutes and some simple tests will get it working.  How you message the user is up to you .  You could use a message box in vbscript.  The script could run once a day or more often and if the time limit was up it would cause the user to click OK everytime the task was run.

    You could also query AD to see when the last time the users machine was authenticated on AD and then send an email to the user saying "E.T. Dial home"

    We could discuss this for days but then you really don't have many options and it is still up to you to make the choice.

    I would just notify all users - "If you do not bring your box in once a month then no one will be reponsible if the box crashes and not one can fix it"

    You could also install InTune and have complete remote access to the boxes for patches and software updates including password changes.  InTune was designed for use in schools and other organizations with infrequent connectivety to home-base.


    ¯\_(ツ)_/¯


    • Edited by jrv Tuesday, May 22, 2012 11:36 PM
    Tuesday, May 22, 2012 11:30 PM
  • I want to say thanks for all the suggestions.

    I will work on non-technical solutions to getting machines back "home" on a regular basis.

    I'm still disappointed that it appears that a user can't really know if they logged in with cached credentials or not.  That seems like an odd thing to restrict on purpose and an oversight if not by design. 

    One reason may be that the event viewer shows all logons, and there may be situations where it is not appropriate for one user to know that kind of information about another user.

    Our users can tell the difference, though, because they know whether they are in the office or connected to the internet; they can tell when the logon script doesn't run; and by the fact that they have no access to our network until they establish a connection.

    Our domain logon script creates a short log file in the user's %temp% folder to document its activities for debugging problems such as shares not getting connected. If I needed to do what you first posted about, I would just have a script examine the time stamp of that file.

    Actually, if I felt prompted to do something like this I would give my head a shake before spending much time on a a scripted approach such as you propose. This puts the user in the drivers seat, whereas it should be you doing the driving. What I mean is that you will not know when or how often a user has been notified. If not notified, this could be because he never uses the remote computer, he has disabled the notification mechanism, or it has failed for some reason.

    Two possible responses when you ask a particular user if he knew his computer needed to be updated:

    a. of *course* I know - I keep seeing that annoying popup message reminding me all the time; or:
    b. how would I know? I haven't seen that little helpful popup message for months. I just assumed for that reasont that it was no longer necessary to bring it in at all.

    Truth be told, the best "scripting" language to use in order to advise users what they need to do is not powershell, batch, or vbscript. It is English. They will probably appreciate an explanation they can understand far more than some clever script. Seriously.

    So, don't look down on the non-technical solutions. And don't expect them (or any method) to exactly solve a problem that derives from how people behave.


    Al Dunbar

    Wednesday, May 23, 2012 3:41 AM
  • PhD uers wil, as a unit, say "drop dead" - my work si moreimporatant than yu trivila "cr***".  I have worked - N-Pole, S-Pole - in between.  A PhD cares litlte about mundane, real-world issues like the condiments served a McD's.

    PhD's care not about your rules.  Take it from one who has lost that battle.


    ¯\_(ツ)_/¯

    Wednesday, May 23, 2012 3:54 AM
  • Agree with the previous comments. I'm not sure there's a scripting problem here but rather a HR problem. If there's no ability to enforce a policy, then IMO you're wasting your efforts.

    Bill

    Wednesday, May 23, 2012 2:14 PM
  • I generally agree with Bill and JR.

    Who places the expectation on you that the computers should be maintained in a relatively up to date state? If this is only you, don't bother. If someone else, then explain the requirement that computers be brought in periodically, and explain that there is no technological solution that will get the users to follow policy. Then leave it up to the policy makers to solve the problem.


    Al Dunbar

    • Marked as answer by Bill_Stewart Thursday, May 31, 2012 7:41 PM
    Wednesday, May 23, 2012 4:18 PM
  • Al - Who is JR?  I thought he died in the last episide.

    On the serious side - I get this from some of teh Admins I have supported.  The idea either comes from a tech who wants to solcve a problem ofr from a manager who thinks it woul be a nice idea for no specified reason.

    As per AL I ususaly push back and have upper management define the rule and enforcement mechanism.  Things like this should never be conceived and enforced out of IT or local management.

    In cases of security we quarantine all returning laptops and do not let them intot eh domain with out a clean up and update.  We do this even if the laptop only left the network for one day.  Some companies require that it be done every time a laptop is removed and reconnected from the domain.

    In the past I have had issues with sale people failing to come i aand upgrade software that is used to submit sales orders.  We handled this by mailing a CD to all sale peopele and asked them to insert it and run the setup code.  This worked becsue we also gave them a month and then disabled the old submission format so that orders could not be submitted until the software was upgraded.  We still got some calls that teh uploads were failing but the help desk could just say - put in the cd and....

    With everything being mobile today I prefer that we don't join remote machines to the domain.  Terminal Server and web make domain connectivity unnecessary.


    ¯\_(ツ)_/¯

    Wednesday, May 23, 2012 5:37 PM
  • Even if this topic is really old I like to provide a procedure which did work for me.

    I just wrote a simple powershell script which looks at the file write age of C:\Windows\System32\config\netlogon.ftl . This file is only updated if the user authenticates with the domain. So if the file write age is older than for example 25 days (our configured password age is 30 days) a message is shown on the users desktop that he should connect to the domain network. The script is started via taskmanager everytime a user logs in. The task has to be run as administrator because only administrators have access to C:\Windows\System32\config.

    Here you go.

    $Now = Get-Date
    $Days = 25
    $Cmd = "msg.exe * <Message>"
    $TargetFile = "C:\Windows\System32\config\netlogon.ftl"
    $LastWrite = $Now.AddDays(-$Days)
    #$LastWrite = $Now.AddHours(-1)
    $File = Get-Item $TargetFile
    if ($File.LastWriteTime -le "$LastWrite")
        {
        Invoke-Expression $Cmd   
        }
    else
        {
        }

    • Proposed as answer by rikmer Thursday, July 3, 2014 12:26 PM
    Thursday, July 3, 2014 10:45 AM
  • Hi,

    Though this thread is old, I found a vbscript which displays a message if user has not logged on to AD Domain for X days and using Cached Credentials. This script is on technet, and posted by Matthew Beattie.

    https://social.technet.microsoft.com/Forums/pt-BR/4ae0f994-e618-44e2-bb1e-1398e0f2bdb1/need-to-expire-out-all-cached-domain-logon-credentials-over-30-days-old?forum=ITCG

    I hope someone find it useful.

    Kind Regards,


    Laeeq Qazi|Team Lead(Exchange + Sharepoint + BES + DynamicsCRM) www.HostingController.com

    Thursday, December 11, 2014 12:50 AM