none
Disable AD user after first successful login (after password change) after x amount of days regardless of activity RRS feed

  • Question

  • I've been searching for over a week high and low now trying to find a way to do this via PS.
    We'd like to lockout certain users (we can put them in a group/OU) 30 days after their first successful log in - the one requiring password change by them.
    And we'd like to disable it REGARDLESS of their activity.

    All the tips and scripts I've found look for 'inactivity', date created etc.

    Only parameters I need are 30 days AFTER the first log in. Accounts might be created 60 days before actual use, but still need to be disabled 30 days after their first successful log in.

    Any tips would be GREATLY appreciated!

    Monday, June 9, 2014 10:58 PM

Answers

  • I don't think you're going to get the kind of solution you want via scripting. As jrv noted, usually this kind of issue is managed by using account expiration and password expiration. If that won't work for you, then I would recommend looking into supported third party tools that can help you get where you need to go.


    -- Bill Stewart [Bill_Stewart]

    Tuesday, June 10, 2014 3:38 PM
    Moderator

All replies

  • And how are you going to know when they first log in?

    Do you see the problem?  There is no built in method for doing this.  You would have to run a process that monitors logins and checks the settings.

    Windows is not designed for this event.

    You might get a consultant to design a process or you can set up login tracking database and have it trigger the setting.


    ¯\_(ツ)_/¯

    Monday, June 9, 2014 11:13 PM
  • That's the issue I'm running up against.

    Tracking that 'first login' event

    Monday, June 9, 2014 11:16 PM
  • You can set a task on the event log on all DCs to execute when a login is detected.  Designing a script to manage this will take someone with good scripting skills.  Consider contacting a consultant.  It is not something that can be done in few lines.


    ¯\_(ツ)_/¯

    Monday, June 9, 2014 11:25 PM
  • Sounds like an approach. But one that might not work in our environment - the event(s) would be huge. I've got thousands of users logging in on different devices and different sites on and off all day. Only need to track (and disable) one subset of those users - doctors across 40+ sites. Same Forrest/Domain though.

    Thanks for the help.

    Monday, June 9, 2014 11:32 PM
  • Sorry but there is no other mechanism. All other methods have a 14+ day resolution.  You can attempt to trap on password change if you set to require the password to be changed on first logon.

    4723

    An attempt was made to change an account's password.

    http://technet.microsoft.com/en-us/library/dn319091.aspx


    ¯\_(ツ)_/¯

    Monday, June 9, 2014 11:43 PM
  • That's what I was hoping to do.

    Capture the actual change of password time/date and then add 30 days to that to then go and disable those accounts.

    Monday, June 9, 2014 11:50 PM
  • So I'd have something to start like this

    get-aduser -filter * -properties passwordlastset,

    and have to also specify the OU (to only grab my intended group) then apply password disable?

    Monday, June 9, 2014 11:58 PM
  • Set a task on the event ID above and capture the account info.  The task will have everything needed to set the account expiration date.

    There is noi such thing as "password disable"

    I think you would be best off by contacting someone trained in AD and Windows networking to help you with this.  This not really and end user or desktop support kind of project.

    You do NOT want to run a continuous poll for on a large and busy AD installation.  It is worse than monitoring the logon events.  Th event ID posted above only occurs when a user changes a password. You only need to check the last logon timestamp on the user account if it has never been used.  This  will be null.  If null set the account expiration date which will disable the account until an admin re-enables it.


    ¯\_(ツ)_/¯

    Tuesday, June 10, 2014 12:17 AM
  • What's the purpose?

    -- Bill Stewart [Bill_Stewart]

    Tuesday, June 10, 2014 12:29 AM
    Moderator
  • I'll try again.

    I appreciate the responses. I do not want to hire an expert, I wish to learn to be one. I understand some may not want to deal with someone learning and that's cool.

    Purpose:

    A new user is created in AD (in a particular OU). New user(s) set to must change password at first logon.

    That new user may or may not make their first logon within any particular time period - upto a 45 days or more from the account creation.

    But once that user has logged in for the first time I then I to disable that account(s) thirty days after that (the user has changed their password/logged in for the first time)

    Tuesday, June 10, 2014 1:26 AM
  • I'll try again.

    I appreciate the responses. I do not want to hire an expert, I wish to learn to be one. I understand some may not want to deal with someone learning and that's cool.

    So what have you tried do far?


    ¯\_(ツ)_/¯

    Tuesday, June 10, 2014 1:29 AM
  • There's no built-in mechanism, but you could create one.  If you've got them in their own OU (hopefully, you are using group policies to control logon scripts),  set them up with a logon script that checks a network share for a file that's named after their user name.  If it's not there, create it. Then do your account maintenance based on the creation time of those files.

    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "



    Tuesday, June 10, 2014 1:35 AM
    Moderator
  • That tells us what you want to do, but it does not explain why.

    -- Bill Stewart [Bill_Stewart]

    Tuesday, June 10, 2014 3:19 AM
    Moderator
  • The reason Bill is asking for the "why" is because "why" can, in many case, uncover a better solution; one that already exists.

    ¯\_(ツ)_/¯

    Tuesday, June 10, 2014 4:00 AM
  • Why is new regulation in our part of the industry.

    All licensed caregivers (Doctors, RNs etc.) must be manually authorized every 30 days. If it were just thirty days from creation that would be easy. But it's thirty days from 1st account activity.

    Tuesday, June 10, 2014 3:09 PM
  • Why is new regulation in our part of the industry.

    All licensed caregivers (Doctors, RNs etc.) must be manually authorized every 30 days. If it were just thirty days from creation that would be easy. But it's thirty days from 1st account activity.

    This is usually done by password expiration or account expiration.  Just set the account to expire in 30 days.  Note to your users that the expiration will require them to recertify.

    The cerification is good for 30 days and not the account.  I have been through this before.  We have ahd numerous medical projects and always use account expiration and a web form to request re-authorization.

    Normally the authorization is for longer - either 90 or 120 days.

    The rules say to just validate the users still alive every 30 days.  This is done by using a web tool and having the user reset their account via a web dialog.

    You can try it your way but it is totally unnecessary which is why you cannot find anyone who has done it.

    HIPAA and federal networking standards require password resets periodically. 30 days is recommended but, as far as I remember, there is not absolute time interval in the regulations.


    ¯\_(ツ)_/¯

    Tuesday, June 10, 2014 3:22 PM
  • Thanks.

    But again if it were just 30 days (or 90 etc.) that'd be easy.

    And it's not just HIPAA either. It's another (state(s) and other regulating groups) policy. 

    Unnecessary, probably. But that is the task I was given.

    Already have a web-form for password re-authorization/reset request. That's no the issue. It's setting expire time to after first use. Example; use created on the 1st of the month. Doesn't login till the 25th. They'd only have 5 days of use before having to be re-activated.

    Guess I'll just go on my way.

    Tuesday, June 10, 2014 3:33 PM
  • I don't think you're going to get the kind of solution you want via scripting. As jrv noted, usually this kind of issue is managed by using account expiration and password expiration. If that won't work for you, then I would recommend looking into supported third party tools that can help you get where you need to go.


    -- Bill Stewart [Bill_Stewart]

    Tuesday, June 10, 2014 3:38 PM
    Moderator
  • My point is why do you think you have to wait for the first login.  Just expire the account in 30 days. Doing it your way will not work.  It may work the very first time but then you will be back to expiring it on a 30 day schedule.  I think you are misunderstanding how the accounts work and what you are being asked to do.  The idea that there are state issue is just not true for any states as they all not comply with the federal rules.  Since ACA that is one thing they have to do.


    ¯\_(ツ)_/¯

    Tuesday, June 10, 2014 3:40 PM
  • I don't think you're going to get the kind of solution you want via scripting. As jrv noted, usually this kind of issue is managed by using account expiration and password expiration. If that won't work for you, then I would recommend looking into supported third party tools that can help you get where you need to go.


    -- Bill Stewart [Bill_Stewart]

    As Bill points out you  need to look into third party tools.  If there is any legitimate legal or industry need for this then there wil be third party tools.  Having worked in medical software systems \I can tell you there is not. There are old systems that use now-obsolete mechanisms that do things similar to what you are asking.  They are no longer usable.

    I think if you sat down with those asking you to do this and had them get the actual industry and government rules on the table you would see that this is not what they are asking you to do.  It aslo doesn't make much sense from a technical standpoint.

    Just set the password expiration.  That is what it is designed for. To force reauth just set the account so the user cannot set the password.  Use the reauth web page to allow the user to set a new password.  Use the corporate disclaimer or a desktop link to notify users what to do when the password expires.


    ¯\_(ツ)_/¯

    Tuesday, June 10, 2014 3:45 PM

  • I think if you sat down with those asking you to do this and had them get the actual industry and government rules on the table you would see that this is not what they are asking you to do.  It aslo doesn't make much sense from a technical standpoint.


    Given the current state of affairs, I won't be surprised to find that they actually did write a regulation that stupid, and expect it to be followed whether it makes any sense or not.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    Tuesday, June 10, 2014 4:09 PM
    Moderator

  • I think if you sat down with those asking you to do this and had them get the actual industry and government rules on the table you would see that this is not what they are asking you to do.  It aslo doesn't make much sense from a technical standpoint.


    Given the current state of affairs, I won't be surprised to find that they actually did write a regulation that stupid, and expect it to be followed whether it makes any sense or not.


    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    Then it is your duty as a technician and one who is supposed to know to educate your users and owners of the technology and how it is used.  Remember what happened at Nuremberg when the techies claimed they were just following orders.

    Besides al of that whayt you are trying to do won't work reliably and will not be secure.  It defeats the purpose for the proclaimed rule.


    ¯\_(ツ)_/¯


    • Edited by jrv Tuesday, June 10, 2014 4:18 PM
    Tuesday, June 10, 2014 4:17 PM


  • Besides al of that whayt you are trying to do won't work reliably and will not be secure.  

    That pretty much describes what the people making the rules built for themselves.

    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    Tuesday, June 10, 2014 4:22 PM
    Moderator


  • Besides al of that whayt you are trying to do won't work reliably and will not be secure.  

    That pretty much describes what the people making the rules built for themselves.

    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    But you are the expert implementing a required security screen.  If you do this without notifying the users that it won't work as required then you are the person who is liable.  If you are just the janitor or a slave then you can just ignore this.  If you are a professional you really need to address the issue.

    In any case, good luck.


    ¯\_(ツ)_/¯

    Tuesday, June 10, 2014 4:25 PM
  • You can't fix stupid, so you may not have any choice but to just walk away from it.

    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "

    Tuesday, June 10, 2014 4:32 PM
    Moderator
  • Okay so I got way more clarity. [I was thrown into this group a few weeks ago. So I'm just trying to catch up.]

    The accounts are for what's called Certification Surveyors. Who are only allowed a one time use account for 30 days from the time they login for each site they'll be at. They might be there anytime after the creation of the account (usually within a week or so). But the account must then function for the time they are permitted to be onsite and conduct audits and inspections and then permanently expire. So I won't have to worry about resetting them. 

    My duty here is to follow the directorates as best as I can, advise, and if possible implement. If I can't then I can't; I don't mind saying so and have never had an issue with blindly following orders - not in my make up. But it is a task for which a high degree of urgency and desire was given. The Nuremberg thing, well that does not sit well with this man and my life experiences. "The only thing necessary for the triumph of evil is for good men to do nothing." Something I've lived by and not just parrot by the way.


    Tuesday, June 10, 2014 4:50 PM
  • Set a task on the logon event (password changed) and script the task to set the expiration date of the account.

    It is very simple to do.  You just need to have a new account flag (use customproperty1-10)

    Just set the task on all DCs.


    ¯\_(ツ)_/¯

    Tuesday, June 10, 2014 4:55 PM
  • THAT is probably the way to do it. I'll give that a go.

    WAY over thought it I think.

    Thank you.

    Tuesday, June 10, 2014 5:08 PM
  • Your security auditors should have squashed the idea of having a bunch of active unused accounts sitting around before it ever got this far.

    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "


    Tuesday, June 10, 2014 5:12 PM
    Moderator
  • There aren't a 'bunch' or as many as it sounds. But the accounts are created when we are told that a particular site will be surveyed (within a window). So we'll create some surveyor users in a particular OU for that upcoming inspection/rollout.
    Tuesday, June 10, 2014 5:16 PM