This topic contains 7 replies, has 6 voices, and was last updated by
December 10, 2018 at 4:42 pm #129060ParticipantPoints: 48Rank: Member
I have been tasked with granting users local admin rights on their PC for x hours, then removing admin rights. Before you start telling me why this is a bad idea, don't waste your breath. The answer is the boss said so.
The first thing that comes to mind is using our management tool (currently configuration manager) to grab current logged in user, add that user to the local admin group, create a task for x hours to remove the user from local admin. It would need to log the user out initially to ensure the user becomes an admin and would need to reboot the machine after x hours to ensure nothing is running with admin creds. The first flaw I see is the user as an admin could simply delete the scheduled task.
Is there a better way?
December 10, 2018 at 4:54 pm #129063ParticipantPoints: 398Rank: Contributor
If you have SCCM in place why do you still need to grant admin rights to the user? If the user is admin he can create another account and grant this account admin rights. Even if your scheduled task removes the original user from the admin group he would still have this newly created admin account. 😉
December 10, 2018 at 7:21 pm #129096ParticipantPoints: 165Rank: Participant
Fully agree with Olaf, fully appreciate that you know its a bad idea, yes, understand the "boss says so" and i'm not going to waste characters... But surely as professionals we should be educating those above and below us?
Is the boss not technical? Do they not see the risks?
If there is a valid technical reason, what is it? Surely there would be a way to automate whatever the boss wants, in which the user doesnt need local admin rights?At that point maybe the guru's on this forum maybe able to advise on how to script such methods to negate the reason for a blanket "all domain users > local admins" approach.
I don't use SCCM, however I've had it in the past where I've needed some users that need local admin rights – mostly developers. I used a domain group, which was applied via Group Policy Preferences for assigning to local admins. That way I could add\remove relatively quickly without faff on the end user's PC. Sounds similar to your method\idea.
I'm really not sure if there is a better way than what you have, or I've done – other than challenging the original reasons\request in the first place!
December 11, 2018 at 12:21 am #129135ParticipantPoints: 487Rank: Contributor
It's all about policy...
You and Olaf have already identified major flaws in this use case, but you have not said, why it's needed (not the whole the boss said so thing), but what does the user need to do during this elevation, that cannot be automated from them.
Install software, SCCM can do this for the user without being admin.
Add a printer, you can do that using PSRemoting.
Maintain a system state that is what DSC is for.
You can set policy to allow users to do things that normally require admin privs without making them admins.
Or even using MSI to install stuff:
If the user gets whacked while in this state, who take that responsibility. ;-}
That would be my push back, and get sing off from the security and risk management teams.
December 11, 2018 at 4:15 pm #129224ParticipantPoints: 48Rank: Member
I appreciate everyone's comments, but your points are moot (https://binged.it/2GbUkRW). SCCM installs are only valid if you have the staff to automate the installs for everything our user base requires and there is sufficient time from the requestor to automate the install. You are also assuming all installers are MSI's which is not true. There are other needs for admin rights that I am not going to bother going into. You are also assuming I have the power to override an executives decision. I currently have three options. Give everyone admin rights on their PC (which is the way it currently is), make a solution to give temporary admin rights that can easily be audited and tracked of who requested it and why, or find employment elsewhere.
Not to be rude, but the attitude portrayed above is I am clearly incompetent and have no business asking for a solution that isn't the best possible security. You are also implying that you never have had to do a less than desirable implementations because of political decisions. Then you wonder why new people are intimidated to ask questions. I realize everyone wants to "Help", but sometimes when people post a question they want the answer to the actual question.
Trust me I am guilty of the exact same thing. I think the best way to handle this is "if you would like information for pushback let me know". I came to the forums for technical information, not a browbeating because of a policy I have been told to implement.
December 11, 2018 at 8:13 pm #129263ParticipantPoints: 487Rank: Contributor
"Not to be rude, but the attitude portrayed above is I am clearly incompetent and have no business asking for a solution that isn't the best possible security."
I don't feel that is the case at all. You asked for alternatives. The folks here are trying to assist with that. If what we are providing is not prudent for your efforts, OK, we get that, but there is no reason to feel insulted / defensive, as that is really not what is trying to be communicated here.
As for ...
"You are also implying that you never have had to do a less than desirable implementations because of political decisions."
I am sure we all have, I know, I've had to, but even in those cases, I had no issues with voicing my concerns to whomever asked for it. Sure, I did it anyway, but reported it up the chain to whomever I could as well. Primarily because, if what I was asked to do caused problems in the enterprise, then blame would be on me, and that RPE (resume producing event) would be on me. Even in my military career, I've had to push back on my leaders / commanders (even generals) for what I felt was an unlawful order(s), based on my command of the military policy / UCMJ / SOP / regulation. Depending on the sensitivity of the action, I still may have done it, after I weighed all the risks for all involved, but I still pushed it up the chain.
So, we all get that position of, because the boss said so, and in those cases, you are asking for alternatives that you'd never be able to use, because that is not what your boss asked for, unless you can convince your boss to accept what you are proposing, which does not sound like you are in a position to do and maintain your position at the company.
So, you few options:
1 – Do exactly as your boss asks (even though you know it is the wrong approach and deal with any an all consequences of such action)
2 – Work the GPO/LPO angle – working the PoLP (Principal of least privilege)
3 – Work the SCCM angle
You are asking for assistance or a solution for a use case that you are saying you can't / don't control as per your own statement, 'because the boss said so'. We too have to live with such things, but it all comes back to how well one can present an alternate view to management and how committed one can / will be to it, to get management to understand the implication of X or Y and why a different approach is needed.
December 11, 2018 at 8:36 pm #129269ParticipantPoints: 48Rank: Member
I have no step-by-step, but openly wonder if JEA (Just Enough Administration) is appropriate. I've not implemented JEA; I've only been reading about it, so theory is all I got.
If the tasks required by the temp elevation to admin can be corralled to executing POSH scripts, would it be an option for a user to start a PSSession, mapped via the virtual account to the administrator, to execute the work?
A scheduled task could replace the role or configuration file accordingly, as to remove access. If the user never gets put into the local admin group, they can't change the scheduled task that would change JEA files.
December 12, 2018 at 1:01 am #129338ParticipantPoints: 98Rank: Member
Also look at just in time administration.
You must be logged in to reply to this topic.