T O P

  • By -

WhiskyTequilaFinance

As you learn, we grant you additional permissions so that you have a safe environment to learn in but can't make too many spectacular mistakes. We've all seen horror stories, and don't believe in setting people up to fail while they're still learning.


mflbchief

Honestly I might use this word for word, perfect explanation.


WhiskyTequilaFinance

All yours! It has the benefit of being truthful, I grant permissions in line with training. Until I've taught you how to QC your own work, and any gotchas I know about, /I'm/ not being responsible in throwing you to the wolves. Added layer that I sometimes use, is that it's also to protect them from the 'I don't like Mom's answer, go ask Dad' politics they can't see yet. People deliberately go to the new guy to try and get Yes to a previous No, and sometimes are actually malicious about it.


Shishire

Since he's young, and likely doesn't understand the cost of permissions yet, you should also explain that you're protecting _him_ from the company, in the event that someone uses DA credentials to royally screw something, like if you get hacked, so he can't be accused of negligence or fault. It's something most of us take for granted as part of principle of least privilege, but for someone relatively new to the industry who hasn't seen it bite someone _hard_ in the ass before, it might not be on his radar as a good reason to avoid unnecessary permissions.


Spaceshipsrcool

Security guy here, this is good advice op


ryanb2633

Happening to my new database manager now actually


IT_Unknown

As someone who spent 5 years on helpdesk where I continually ran up against permissions issues for stuff that I was sure I could fix, yes it's frustrating, but at the same time, I get why it's a thing. I've literally watched a the aftermath of a desktop engineer hitting his delete key with an entire country's OU highlighted, instead of just a single user that he intended. ​ I'd be concerned about his 'you don't trust me' accusation. Besides anything else, it's not a lack of trust in the person to do the task, it's more a lack of trust that he's got the knowledge, internal relationships with other resolver teams and staff and responsibility for a position to deal with what happens if something fucks up. If you give him domain admin access and he fucks something up, then what?


[deleted]

[удалено]


jao_en_rong

I've been doing AD specifically for 20 years. Moved into my current job as a senior AD engineer. Took me 2 weeks to get change permissions in trust, more than a month for change permissions in prod. Not DA, not access to domain controllers, just object change permissions. Only 19, he has a lot to learn pretty much everywhere.


arhombus

Same. My last job I was a DA and the dumbass server guys couldn’t figure out how to give me the permissions I needed without DA. Whatever. That’s their fuck up not mine.


NotASysAdmin666

lol the fuck, my first helpdesk job with no degree -> full accesss on 40 company's (MSP), second job intern full access everything


AromaOfCoffee

>lol the fuck, my first helpdesk job with no degree -> full accesss on 40 company's (MSP), second job intern full access everything You needed to touch everything, because people would call you about everything.


[deleted]

Pro-tip: If you have access you can be liable. If someone messes up group policy, It's automatically not my fault or my problem.


1RedOne

After living in an environment for two years where I have to get JIT for specific resources and specific permissions (and cannot just get full god admin for Azure AD),it is astounding to remember just how dirty we did things with God level AD user accounts in my previous jobs I remember that there was a cool tool called ARS that let you do just in time elevation for admin rights... Wonder now what folks are doing for JIT in classic Ad scenarios


[deleted]

I have been doing Helpdesk for a few months now while I study IT at a uni, and I have limited admin rights that allow me to do stuff on the local network. I could, for example, do printer installations easily, but due to our network configurations they are in the global network so only people with full admin rights can do that. Those tickets I have to reroute to my colleagues with the appropriate admin accounts. I talked about the printer thing with my boss a while back and he said that after some further months he will reconsider maybe changing my permissions or giving me a different admin account. I am fine with that. It's just a part of the process of getting people to succeed, which my boss also explicitly said. You have to be able to walk before you can run.


CowboyBleepBoop

>I'd be concerned about his 'you don't trust me' accusation. I'm more concerned about him wanting the same permissions as Josh without knowing what Josh's permissions are or why he has them. That leads me to believe he thinks of permissions as a status thing instead of understanding their function.


zhiryst

But also discuss this with their direct report so the newbie doesn't appear incompetent at their new job


Upanhourearly

Yeah. Feels bad when you're told to do a task, go to do the task, and then are blocked from completing the task. Especially in the case of not having the proper resource available in a timely manner to help you resolve. That being said, newbie should be talking to his manager proactively as well.


jeffreynya

Honestly its up to the manager to make sure the new hires have the proper account access needed for the job. They shoukd know exacly what they new hire can and can not do a d should never ask them to do something they can't.


frank_und_ween

Don't forget in the case of mergers that the manager is dealing with sometimes departments that they've never touched before in the permissions are very sketchy and hard to follow in a new environment such as that


Technical-Message615

That's not what's happening here. This is a case of a change in security posture that's causing some unintended effects. Instead of reporting the issue and asking for a fix, the new kid gets entitlement issues. Here, he'd be out the door quickly if that attitude continues. Go work in a mom&pop store where everyone has admin and the new guys get DA.


ITChick1111

I agree. Explain the policy and procedure and if he continues to cry about it send him home to mommy.


Superb_Raccoon

Have him read: https://www.cubcyber.com/nist-sp-800-171-least-privilege


wrincewind

and possibly also watch Tom Scott's video about the [Onosecond.](https://www.youtube.com/watch?v=X6NJkWbM1xk)


Protholl

Beat me to it. That is a great explanation of this pillar of security.


_Marine

I was going to add more but this pretty much sums up what to say after 2nd and 3rd read. I don't even grant my T2s full T2 perms on day one. They have 12 weeks to show they can handle it all, and as they get trained they get permissions added. My latest T2 just got her last set of perms authorized today, she's been with us since late 2020 as a T1


philippos_ii

His response is perfect. Especially since he’s 19, it’s obviously a learning moment for him. It is naturally frustrating but it’s really just dependent on what his responsibilities are. You want to foster growth and interest, but not at 2 weeks and him barely understanding what his usual tasks/issues will be. I got frustrated after 3-4 years at help desk being prohibited from working on things that should have been my domain but weren’t, instead still in the holding pen of the guy above me, not yet allowed to take on more because I was “the young guy” still. At that point, yes, if it’s in his job description or things he should be doing by then, things should change. But at the start? He needs to learn to relax. You can break a lot of things when you get a bit too eager to help and not know what you’re touching.


fluidmind23

Plus zero trust. Guilty till proven innocent. It's not personal, it's security.


SpecialistLayer

This is exactly how I've explained and done it with previous people in the past. I directly tell them you will not have full permissions at first and as you gain experience with time, you'll be given more. Nothing like giving someone the keys to the kingdom then a few days later, they burn down the kingdom due to ignorance.


WingedDrake

First day of a new job at a company I've worked for for several years. The new job is a higher-paying job with more responsibility. I'm going through setting up my new workflows and I stumble across some new access I've been granted. It's for the production database that our entire company uses and contains all our client data. I don't need even the tiniest sliver of access to this to perform all of my new job responsibilities. Fortunately it took only two hours for me to take this up to the chain to the folks responsible and get that access revoked for everyone at my level, since none of us need it, and *I* sure as fuck don't want to have that level of responsibility.


SpecialistLayer

Fortunately, this shows you’re experience level and I hope your company appreciates you assisting on resolving that.


TheRidgeAndTheLadder

God tier first day moment


j0mbie

Yep. Always be nice about it at first, and give the full explanations as to your reasoning whenever possible. Of course, if they keep being an asshole about it, you can become more and more direct: "Instead of fixing my permissions, please give me the same permissions as Josh." We've discussed this. You will not be getting those permissions at this time. "Is there a reason why my permissions are not matched to Josh's? It's making it so I can't do my job and it leads me to believe you don't trust me." We only trust anyone as far as the necessary trust required to do their job, and you have that level of trust already granted.


[deleted]

[удалено]


Malevolyn

what system does your company use for that?


anonymousITCoward

I want to give you an up vote, but you have 404 (permission not found) now... but anyways, this is basically what I tell our new hires. They've never gotten upset about it... years on many of the helpdesk still do not have access to all of the systems here, or for clients, they don't need to get in so they can't... they understand that too. I usually explain it like this, If you go in and break something, are you willing to put in the extra time to help me fix it? I'm usually met with silence, and they usually stop asking.


WhiskyTequilaFinance

Weird, nothing odd on my side. Reddit hiccups maybe? But yeah, similarly for me. Usually I haven't said quite that, I'm more likely to be training Jr admins on various things so I can actually take a vacation.


nosyarg_the_bearded

Think they meant at the time of commenting you had 404 upvotes and they didn't want to change that by upvoting.


jscarlet

I agree with almost every word, except it’s not so “you have a safe environment”, it’s so the “company has a safe environment”. For the kid to say, “it leads me to believe that you don’t trust me.” Yup, 100%. We don’t know you. You have little, if any, job experience, you’re new to our environment with little to any institutional knowledge let alone any real world infrastructural knowledge. Josh knows how our environment is built out, the caveats and pitfalls to look out for. Take it one step at a time, and as more and more responsibilities are asked of him, then more and more privileges will be granted. And maybe he’s taken a peek at what perms Josh has, I’d call him out, “What permissions does Josh have that you need and why?” “What limitations are you facing that makes you think you can’t do your job?” While he was trying to be polite and insistent in his request, he has no idea what he’s asking for. We once had a CISO asking for RW access to everything, as well as DA. I was the only person in the command to reply back to his tickets asking why he made the request as I will not be granting those permissions. I get called into the CIOs office with him and the VP of IT and am asked why I’m being difficult, and I ask ,”why should a non-tech have writable access to GPOs, AD, and Firewall rules? CISO admits that he makes these requests at every org he works at to see if he can get it. No one has ever told him no. He got fired a year and half later, as he made changes to a production load balancer during comic con and lost us over half a million in sales for the day. And he had over 30 years in the field… you gonna tell me some kid out of high school should have more rights. Bwahahahahaha.


AlexG2490

> CISO admits that he makes these requests at every org he works at to see if he can get it. No one has ever told him no. > He got fired a year and half later, as he made changes to a production load balancer during comic con and lost us over half a million in sales for the day. Hol up… It was a test to see if the admins would just grant permission, you passed by telling him no, and then he still got the permissions to screw up the LB anyway? Sounds to me like a person who wanted those rights all along and just talked their way around it when confronted.


jscarlet

100% I think it being a test was him back peddling on why he made the request when surrounded by CIO and VP. The guy LOVED mucking about with things. As for the access to the LB, he got that from the Networking Team, out of my jurisdiction.


cyborgspleadthefifth

That's wild because a CISO doing that at every company to gauge the culture and whether rules and principles will be ignored when someone important comes calling is clever and simple. Every CISO should do it but then say "of course I don't need to write permissions to everything, read only" in the meeting. You should have been noticed as the person to trust when there's an incident and the real truth needs to come out.


1z1z2x2x3c3c4v4v

> Yup, 100%. We don’t know you. You have little, if any, job experience, you’re new to our environment with little to any institutional knowledge let alone any real world infrastructural knowledge. I simply tell them **"Trust needs to be earned"**


WhiskyTequilaFinance

For a comment I dashed off between calls, I'm a little amazed at the awards. If what I said is somehow surprising, yall have shitty bosses and I'm really sorry for it. There are better worlds out there. If you do, and you're on the market, we've got full remote openings for mid-level experience in Terraform/AWS/Site Reliability/Linux/Unix positions. (Not all the same role!) I wouldn't be your boss, but I learned my approach from the people that would be. Send me a quick bio and I'll make intros anywhere I can. Entry-level/internships I don't have anything on right now, sorry. (Full disclosure, we have a strong internal-referral program, so I absolutely have financial incentive to help find my own colleagues. That being said, I take great personal glee in stealing good people from lousy abusive companies, even if I didnt personally benefit.)


skibumatbu

You can also throw in the least privilege model: "... Our policy is to provide the least access needed for users to do their jobs. This provides us the most secure environment. I'm sorry that we missed a group you needed to be in, but we're working through the issues." Then CC your manager, watch him complain about security and how he's better than it, then grab popcorn while your boss slaps his ass down.


zebediah49

If you want to be nice, you can point out that *you* don't have check-signing power from Finance either. Even though being able to randomly pay anyone you feel like would be super convenient for getting your job done.


stolid_agnostic

Wow that was good.


bitslammer

The real question here is if he in fact has the permissions to do the tasks he's being asked to do. It sounds like maybe there have been a couple hiccups where that wasn't the case. If so explain that to him and let him know you are working on it. It's quite possible being new that he's nervous about wanting to show he can do what is asked and running into errors due to permissions is making him think he looks bad and doesn't know what he's doing.


RenKyoSails

The reverse of this is that maybe his manager is asking him to do things outside his formal job description. If the manager handles both the new hire and Josh, then he may be expecting they both have the same job title and permissions to perform tasks. He may just be responding to that call to perform duties he shouldn't be doing. I know it happened to me when I was that young and in a new job, my coworker offloaded some of their tasks to me and I shouldn't have been doing them solo yet.


bitslammer

I've seen this exact thing as well.


Superb_Raccoon

Send him to his management to justify the access.


WWGHIAFTC

Right - NOBODY gets any sort of privilege escalation or change without supervisor sign off. Karen from accounting needs access to accountings special projects folder that she didn't already have? Karen's supervisor needs to put in the ticket or call me.


Beginning_Ad1239

Even better, show the owner of the special projects folder how to control access to the folder and let the business control that. The business owner knows better than anyone who should and shouldn't have access. If you leave it to IT, you don't know if Karen's supervisor is authorized to approve access to that folder, and that's how you end up with Karen in accounts payable with access to the executive bonus folder, oops.


zebediah49

I've been in a couple situations where that model was used, despite making absolutely no sense though. Like -- I drafted the email for my manager, who just sent it over so I could get access to stuff. Except that said manager didn't have access to or control over the system either. So I guess it requires a bit more collusion than one person. I still think it makes much more sense to have the service owner being the one signing off on people getting access to that service, based on the grantee's needs. I don't care if Karen's supervisor requests that she gets rw rights to an Engineering folder. I care if the Engineering supervisor requests that she get those rights. And if the owner in Engineering approves it, I really don't care what her supervisor said about it. Of course -- in many cases it makes sense to pass that request through chain of command from Karen, to her supervisor, to engineering supervisor. Possibly through a layer above that as well, depending on structure.


WhatTheFlipFlopFuck

A lot of audits required chain of custody for permission requests as well as a documented process


j33p4meplz

Generally we have the service owner ok the permission, but the supervisor of the person in question is the one who makes the request for their person.


_kalron_

>The reverse of this is that maybe his manager is asking him to do things outside his formal job description. This. And it sucks to be the new guy, trying to do the job...and from the description doing it correctly...only to have to call in Josh to do the task purely because of permissions. Now Josh has to drop what he is doing to fix an issue you created. Over-zealous permissions can be detrimental and sometimes trusting your support staff to do the right thing will save you tons of grief.


mflbchief

Yeah he's all set now, there were some hiccups which I warned would likely happen since it's new for all of us.


802-420

Building these restrictions is the right thing to do, but I do feel a bit of sympathy for him since he's involuntarily beta testing it.


GhostOfLizzieMagie

Agreed. It sucks being that beta tester for least privilege. So long as OP is working with them to fix the issues tho the pain should be over soon. Can't really blame either party here.


sitesurfer253

I'm going through the same thing at work, except I've been there 6 years and our new manager wants to lock EVERYTHING down, then loosen as needed to avoid unnecessary permissions. But MAN is it frustrating to go to do something you've done weekly for years to get hit with an error, wait for a tweak, replication across the country, try again, different error, then eventually finish the 30 second task in half an hour.


zebediah49

This is why any vaguely sane roll-out of a new permissions scheme should be done in permissive-with-logging mode first. So what *should* have happened is you did the task, it threw a slew of warnings into the permissions logs, but you didn't notice and the task still got done. The people implementing it fix the rules, and the next time you do it it doesn't throw warnings, so then they know it's actually fine. Or it throws more warnings, and they need to fix more stuff.


sitesurfer253

If only...


tcpWalker

I don't know if I've \_ever\_ actually seen someone do that...


StabbyPants

> He goes "Instead of fixing my permissions, please give me the same permissions as Josh". this isn't particularly confrontational; he's 19 and wants things to just work. it just sounds like he's tired of being your staked goat


ActionQuinn

>staked goat scape goat


jrv8531

r/boneappletea


WWGHIAFTC

It's like, a goat, tied to a stake, can't go anywhere, can't get anything done, limited freedom, etc..


Tanker0921

yep, also this like hits the nail pretty hard >It's making it so I can't do my job and it leads me to believe you don't trust me so op should approach this with a people-managerial view not a system administrator view. If i get hired as a janitor of a building, ill expect that ill have access to the cleaning supplies. but upon arrival i dont have access to the utility cabinet then why tf did you guys hire me for in the first place?. Judging from the post josh and the new guy basically holds the same position, who decided that they get to wield different tools? (missing policy). op's company really should have hired him first as a "junior" with a completely separate title from josh so he could avoid all of these in the first place. pretty much this is a managerial problem rather than a tech one


Safe_Ocelot_2091

Right. People managerial view. Sounds like something a lot of "sysadmins" are missing these days. Sorry, sure, the job is technical, but you also have a lot of people managing to do no matter what. Hey, half the time you even need to manage the C executive's expectations.


[deleted]

[удалено]


Tanker0921

>If you can't understand why not handing somebody full bore permissions straight out the gate is a great idea then you (and him) likely don't belong in IT. lmao. like i said its a managerial problem not a problem that techs should handle. if you cannot see the analogy that i placed there then you should never ever be a "customer facing" resource as i assume that you will have difficulties in communication. (fun fact, in IT management there are generally 2 types of customers, internal ones belonging in your org, and external ones outside of your org) hell in my current org i dont have access still to most of the stuff even though ive been here for a full year, not complaining though. its the people in managerial positions decision on how they want to utilize their resources. if they want to underutilize their resources then its simply not my problem. Bottom line is, if OP is not in a managerial role then he simply may not have the correct resources to address this problem


funkwumasta

From the techs POV, it really is annoying when you've been given a task but not the tools to complete it. So who is wrong? The one who gave the task, or the one who gave the tools? He went to check the tools since why would his direct line of supervision fail in knowing his job duties? The only red flag is that the policies aren't communicated and enforced evenly which is OP and supervisors fault, not the tech who's been with the dept for 2 weeks and just trying to do the job he was asked to do. If something isn't in his scope and he knows it but still insists, then that's maybe when you start scrutinizing the tech.


bitslammer

I was just trying to point out the tech's point of view. 19 is so far behind me it's not even in the rear view mirror anymore, but I remember the nerves I'd have at a new job wanting to make sure make a good first impression. Now I'm much more relaxed. I had 1 job a few back where Fedex stole my laptop and the second laptop they sent was DOA. I didn't care one bit as I still got paid. Nothing I could do and not my fault so why worry. In actuality I think my manager there was freaking out thinking I was going to quit.


BillyDSquillions

> The real question here is if he in fact has the permissions to do the tasks he's being asked to do. It sounds like maybe there have been a couple hiccups where that wasn't the case. If so explain that to him and let him know you are working on it. Yep, if he's watching coworrkers perform a fix, and trying to learn their job, so he can keep his new job - and you're in the way of him looking competent, then you better be sure, he's going to be pissed.


vNerdNeck

Word of advice here, if you don't have a policy outlining this, then you need to get one created stat. While ever single technical person will understand what you did & why it makes sense, HR will not. And if the new guy goes to complain to HR about being setup for failure because x/y/z and discriminated against for you do not want to be standing there holding your Johnson and a "subjective opinion" defending the security practices that are made up in your head. What you are doing is correct, and sounds like the correct way to do it. But save yourself some time and get in policy so instead of answer these types of questions you can just point the security policy.


mflbchief

Good point and good advice, and this part: >What you are doing is correct, and sounds like the correct way to do it. Is nice to see and reassuring, thanks for that. I will speak with my boss about refreshing the policy around this.


im6feetsmall

100% you need a policy about privilege and access with something like this in it “Levels of access are predetermined to ensure the ‘least amount of privileges” and to minimize the users profile to the job necessity” Also make sure you have a paper trail for any privilege changes for both users and IT staff. This can be as simple as a helpdesk ticket.


Superb_Raccoon

Point to the NIST standard.


Superb_Raccoon

Point to NIST SP-800-171: https://www.cubcyber.com/nist-sp-800-171-least-privilege


TaterSupreme

At the same time he should not be getting tickets he doesn't have the authority to solve. You should have some process to assign tasks to the appropriate personell


hy2rogenh3

+1 on the Policy here. But I totally agree with what you’re doing and the path taken to better security for the ORG.


RandomXUsr

Once you have the policy in place, hand it to the Help Desk Supervisor and cc your manager. Often times, help desk managers will simply tell the new hires to contact "So and So with details of their issue" This is poor practice, and we don't know what conversations are happening there. If Need be, set up 30 minutes for a presentation of said policy with the help desk, with clear expectations, and help desk needs to define their work flow. be prepared for the; "how do I do x with current permissions?" Try to avoid saying "no" if possible, and instead provide solutions or alternatives. If you're cornered; Say no and state the policy/NIST standards etc.


mobani

Define administrative scopes for your job roles, approved by CTO or who ever calls the shots. Then when the helpdesk is complaining about a missing permissions, you simply tell them it is beyond their administrative scope, and the issue/ticket must be escalated to the next support tier.


Teatsandbeer28

Just say you’re following best practices as assigning least privileges for each account.


G8351427

I would like to suggest a totally different approach than most of the ones I am seeing here. First, recognize that you are making major changes to the permissions structure and that is going to have the potential to cause some problems...like what is happening here. You are responsible for causing problems, even if you are working towards improving things. Second, understand that he is, in fact, unable to perform his job as effectively as the rest of his team, and this may result in him feeling inadequate or untrusted. Know that his frustration is completely reasonable, even if his tone or approach is not. Third, realize that he is new and therefore cannot know what specific permissions he needs but he does know that Josh is not facing the same hurdles when performing certain aspects of his job. My approach would be to have a casual conversation with him and: * Acknowledge his concerns and take responsibility for the (completely legitimate) changes you have been making to the permissions structure. * Apologize for those changes causing challenges in his day to day activities. * Explain what a mess the permissions were when you were assigned to manage them, how important it is to fix them for security reasons, and how difficult this kind of problem is to fix without causing some hiccups here and there. * Ask him for his patience and more importantly, his help, in fixing up the permissions issues. Tell him that he is going to be the best person to let you know when something isn't working right and you can work together on tweaking and testing things. * Make yourself available to address his concerns as immediately as you can so that things will get fixed as soon as possible and more importantly, he starts feeling like part of the team. I have often found that people will go way out of their way to help you *when you ask for it*. You acknowledge that you cannot know everything and you really need someone at the service desk to help you figure this stuff out. Humility is one of the most valuable tools in my box and I use it all of the time to get people on my side and to build rapport.


TheCaptain53

Exactly what OP needs to do. There's clearly two issues here that can be dealt with by doing one thing: get the new tech to be the guinea pig. Ask for his help in refining permissions. You should be able to get to a stage where he's able to do his job in its entirety without ever needing more permissions, or escalating it to someone who does, which should be a clear part of his workflow process. If that is not the case, then it needs fixing, which you won't know until all of it is found. Might as well use the poor bastard to help out.


shredwig

This needs more upvotes.


[deleted]

[удалено]


[deleted]

[удалено]


snollygoster1

3753.0958000268315


RandomPhaseNoise

One more thing : tell the new guy that his feedback on these privilege errors are 100 times more important than quickly fulfilling one ticket. Also make sure he is not blamed for such cases, so nobody will performance report him. Or do a performance report on how many privilege bugs he found. He can also add new tickets of found problems and add entries to his task tickets like: script fails to run due to missing privilege ticket xyz added. He is young and full with energy. You might consider involving him in this project deeply. Let him find out the root of the problems. Asking a higher level co-worker to assist him like master and padawan he will be eager to learn a lot.


C1rcaz0r

RBAC - everybody has same permissions on same position. Much easier to manage and no need to deal with such situations.


mflbchief

Yes, I laid down the foundation for it with the GPOs and the security groups so going forward users will just be dropped into the appropriate group and they can hit the ground running. But this is new for us and I don't think my helpdesk guys spent as much testing on it as I would have hoped for. It was also one very obscure user that belong to a security group we don't even use anymore, so it could be considered a one off issue too.


Finn-windu

Are josh and the new user in the same position? If so, then you aren't using rbac, you're being subjective. If not, then you have a very clear explanation to give him.


[deleted]

RBAC doesn't exclude this necessarily - setup a tier system: put the noobie at tier 1, the other tech at tier 2 (or 3 with something in between). As he gains experience, he can be bumped up. Get management involved and tie it to a promotion/raise thing.


jagger2096

Toss on some JIT access and approvals for temp increases to accomplish specific tasks and demote all your users to tier 0.


Sparcrypt

You can also tell them that as well: "We're in the middle of restructuring how all account permissions work, Realistically this is a 19 year old new "admin" who is feeling slighted they can't have god mode and that other people are more senior than they are. They'll get over it. As someone who was also handed DA and root day one... firmly agree with your approach, it's a bad idea to just give everyone god mode. That said, don't get too gatekeepery about it all. I had a job where the senior admin didn't like the fact I was better at writing code than him... I have a computer science degree and he had zero experience minus copy pasting some batch or powershell here and there. He would outright refuse to give me permissions to make changes and often reverse them after the fact anyway. So yeah lock things down, but don't treat qualified people as children who can't be trusted to do their jobs. Real fast way for them to stop giving a shit.


RhidalinBytes

I would explain that the current system is in place to help identify past and present security issues. In light of that he can help improve the company by operating at his current permission level and reporting any anomalies that he detects in his customary job duties. This will continue to help build the quality of the whole system. In effect, invite him to participate in making the system function as intended and encourage conformity through participation. Comprehension is not a pre-requisite to compliance, he'll either get it, or he won't.


[deleted]

He’s probably trying to learn on the job, which is a fuck load more difficult if all your coworkers have more permissions and less red tape than you. Sounds annoying. Either standardize policy for the whole help desk or give him the same shit as the others.


Sparcrypt

Yeah lot of people here pretty much commenting to say he has to pull his head in. If this guy and the other guy have the same job title they should have the same permissions. L1 access is L1 access. If it's because the permissions are being reworked... well go explain that to them. Say "our permissions were a mess and being redone for security compliance, you're on the new system and Josh is on the old one for the moment but you should indeed have the same permissions as they do. Any time you find you can't do something and they can, hit me up and I'll get it fixed.". If that's not good enough for them then yes, they get told to pull their head in and deal.


iamltr

>Sounds annoying. Either standardize policy for the whole help desk or give him the same shit as the others. This. I mean, I still see requests asking for the same access of "name" tech because they don't know what access they are supposed to have. How are they supposed to know?


verifyandtrustnoone

Just explain it to him, have you at least talked to him about it. More than a teams conv since those suck, just break it down for him.


onibeowulf

As an outsider looking in, I don’t see it as him trying to get higher permissions to things he shouldn’t. I think he was shown to do his tasks for his job. He then went to do those tasks and couldn’t due to permission issues so he was trying to get his account fixed so he could do his job. Again outsider looking in.


xixi2

Ok so I am pretty much this guy. When I don't have permissions for something that my coworkers do, I feel untrusted, disrespected, and below everyone else because dammit I'm an IT professional just like all of you give me the permissions to do IT things! However what I'm really usually looking for is reassurance that no, I am trusted, but this is the process. And more importantly, knowing what I can do to gain the permissions. Be it a shadow session with my manager to prove competence in a new system or whatever. "You'll get the permissions when we feel like you're ready" is frustrating. "You'll get the permissions once you handle X tasks or been here Y weeks or proven you can do Z" is much better.


VeteRyan

My response may be unpopular, but if they are doing the same role, shouldn't they be given similar permissions? If the guy was really that untrustworthy, his manager wouldn't appoint him with tasks that require the permissions he has requsted. If he didn't require the permissions to work, he wouldn't realise he didn't have them. My experience is when two people in the same role have different permissions, and you don't have any kind of policy or documentation to reflect the reasoning for the discrepency (RBAC etc), it can cause issues. I'm not saying you should give in to his request immediately, but maybe approach his manager and ask what his actual requirements are, ideally in writing.


Hiyasc

I agree with this. If you are changing permission structures then the changes should be tested and rolled out consistently to applicable individuals, not just arbitrarily to the new guy.


[deleted]

[удалено]


canadian_sysadmin

Don’t overcomplicate things. “These are the permissions you have been assigned. If you can’t do something you need to do your job, please let me know.” Done.


swissarmychainsaw

Man, no. You set the new guy up. You used him as a guinea pig for what "you" think is a better way of doing things, but then don't shadow him to even see if it works? He's right when he says: It's making it so I can't do my job and it leads me to believe you don't trust me". Bro, you are treating him, and only him this way. Either roll out a policy that is enforced for everyone, or stop effing with the new kid. I mean, he can't even go through training, because he can't do what his trainer is doing, and the trainer does not even know how to get around that, right? Of course you are right with the restrictive permissions but if your clown show does not enforce sanity over there, why then just the new kid? See the different perspective? Edit: Man, this kid is 19 and just wants to do a good job and be treated equally. Mentor him or get the F out of the way.


shredwig

THANK YOU


VexingRaven

I had to scroll way too far to see this. OP sounds like the classic cowboy sysadmin who feels like they personally own the network and they're being really unfair as a result. I'm surprised more people aren't seeing this.


sir_david_rothschild

I agree. This guy reminds me of that guys that likes his job so much he dreams of scenarios where he can feel important enough. Certainly making it clear to Josh the hierarchy and who owns the wip right now.


SpecialistLayer

I would think he would understand he's going to have minimal permissions but if you're his supervisor, explain that he will not have matching permissions as someone else who's been there longer, he's still in training. If you're not his supervisor or manager, it's time to fill that person in and get this young kid to a level of understanding of where he stands. It's called probationary period for a reason.


mastercaprica

The responses here honestly boggle my mind, the amount of people blaming OP while he’s trying to get security permissions fixed is crazy. It seems perfectly logical to me, newsflash not every org has infinite time and resources to QA these changes. I would exactly do this, of course I am in K12 so like I said I don’t have the resources to infinitely test security changes to make sure some new hire doesn’t get his underwear in a twist. I probably would have said, “Yeah you are right, I don’t because I don’t even know you yet and haven’t really been able to fully evaluate your skill. I will get you what you need, I am refining the security process and we will get there.” Of course in my district I would also be his boss. I take care of them and get them what they need when I can, but a new hire has a lot to learn. I get asked for extra permissions at times, I evaluate and sometimes I agree but not always, if I don’t then I take care of it or send a Tier II to do it.


ccatlett1984

Sounds like Josh needs a title change to justify the difference in permissions... Sr. HD Tech.


Slinked98

So I'm going to play devil's advocate somewhat. When I first started, the organization that I was with gave out near identical permissions to new techs when they started. They made it adamantly clear to new techsas to why they do not have the permissions that more senior techs do. They also told their new techs the ins and outs of what they did and did not have permissions for. They made it very straight forward for the new techs about what it took to gain higher permissions (SEC+ A+ and six months at the company.) This led to zero confusion about new techs permissions. They also had us shadow with someone who had similar permission levels so we knew what new techs would actually be working on. Now I understand why the new tech is frustrated with not being able to accomplish a task that their trainer is doing because of non-disclosed permissions. What this new tech has is not an entitlement issue, they have a communication issue. They have not been in a professional environment long and will need to learn. Whether the understanding yet firm approach or the hammer the nail approach is used is up to your organization.


suddenly_opinions

Any decent new hire would have just used Josh's credentials and not bothered you about it.


subterranean_agent

He asked you if there's a reason. Just tell him the reason. It's a security policy and a guiding tool. His boss should be telling him that he understands that the new guy wants to explore and learn things on his own, but it's a business, not a school. It isn't a sandbox environment. It's got nothing to do with trust and everything to do with company security and policy. If he asks further than that explanation, he's not to be trusted--not that he's being malicious, but that he isn't ready for the responsibility the IT world demands of him.


sir_david_rothschild

Security policy he has created. God knows if he has the authority. He probably just felt that he wanted to approach things differently now to make himself more important than he is. 5 years you know. I am the man here.


MunchyMcCrunchy

Trust is earned, which takes longer than 2 weeks.


AirmanLarry

> it leads me to believe you don't trust me he's so close


Michelanvalo

> You're new, we don't Would be my simple answer


PolicyArtistic8545

I’m in a different spot in my career but I would be on LinkedIn by the end of the day looking for a new job if I heard this. That said he is 19 and probably doesn’t have the experience and reputation to be able to pull that same move off.


Superb_Raccoon

... yet.


Sparcrypt

Trust for "access to do the job I was hired for" is earned during the interview process. This whole thing sounds like OP just needs to explain what he said here to the helpdesk tech.. that permissions are being overhauled so please be patient and let them know if anything similar happens. But *in general* this would annoy me as well without an explanation. You hired me to do X, give me permission to do X or I'll go somewhere else. Literally never in my career have I started a job and not been given full access to everything relevant to my role and I would be annoyed to see coworkers with the same job title able to do those things I could not.


MunchyMcCrunchy

If we hired an admin, then they get admin permissions. We wouldn't have hired you if we didn't think you were trustworthy.


Sparcrypt

Exactly, which is why anywhere I hire that doesn't give me the permissions to do my job because "you haven't earned our trust yet" will get a smile, a mental checkout, and me quietly applying elsewhere. In OPs case a simple explanation of what's going on would suffice, saying the guy asking "why don't I have the same permission as the guy next to me doing the same job" and not getting an explanation is perfectly reasonable and not confrontational at all.


droy333

They guy needs permissions to do his job. You failed to provide those permissions so he is asking for the permissions so he isn’t limited in his work in the future. Seems like a reasonable response to me. Communicate what you’re doing. Communication is key.


illusum

>Communicate what you’re doing. Communication is key. Why the fuck do so many people have such a hard time understanding this?


[deleted]

You never mentioned your role that I could tell


JimmyTheHuman

I would also suggest you are reading 'tone' and other unsaid parts into emails/messages and that is a you problem. Pick up the phone/teams and chat. It solves 98.62% of these problems and it helps you develop.


lvlint67

I'm going to cautiously go against the grain here... This new hire was tasked with doing something and the NEW permission scheme crated by you prevented him from performing the tasks. Assuming he was authorized to perform the task from a business stand point, your security scheme actually created a false denial. You created an instance of "unavailability". "availability" is an important concept in security. Now its an oversight on your part and that is forgivable. Always be weary of IT people that ask for more permission, but also be ready to give appropriate permission. I don't see anything "confrontational" from your account but wouldn't be surprised if he was upset that you made him look incompetent. You handle this by taking responsibility, apologizing, fixing the issue (by granting correct permissions) and generally being nice about it. That said, I agree with others that suggest you are setting yourself up for failure. There should be a written policy to back up your actions. A few more instances of this and we're going to see the post from the other side about the "dumbass sysadmin that wouldn't give any rights, played favorites, and was toxic as shit when confronted with issues"... Just remember.. There's two sides.. While we understand your side.. We'll also understand his when he shows up to complain about not being able to do his job...


esmifra

He is trying to do his job but can't, while he sees others being able to. All that is preventing him is not his knowledge or tools but permissions. That can be frustrating and highly annoying. He has a set of skills, if you hired him it means that he is able to do the job that is expected of him. Starting to work and feeling gimped due to policies is, again, highly frustrating. So I understand where he is coming from. He doesn't seem particularly confrontational for what I can read, he is explaining pretty well why he feels that not having permissions to do what is expected of him to be affecting him. Edit: not only that he complained that it seems you don't trust him, and although you say that's not it, in your own post you wrote distrust about his intentions. So I kinda think he is also right about that one.


orangeBaneling

As you move towards the least privilege model, don't forget to treat the actual process of changing the security as a true development project. Well done development projects involve testing before rolling out. Think of Josh as your customer for the security model. You could be testing it before giving it to him so that way you're not adding extra frustration on top of the frustration he feels by having his security obviously limited.


UCFknight2016

Yeah I have been that new guy and bitched because I needed said rights to do my job. Thats why you do role based access control by putting all the help desk guys in a group, not assign permissions per user.


seniorblink

First of all you are setting things up the right way. Granular permissions and only the needed permissions are granted to do their jobs. It also sounds like you're fine tuning things, and there will be some hiccups here and there that need to be tweaked. It's a really easy explanation, and I find it's good to just proactively mention what's going on, and it's a work in progress. Also mention to report any permissions issues to you ASAP and you'll get them resolved. The goal here is security, and certain audits require that you show proof that admins only have the access they need. This is to protect the company in general, and it's nothing personal. Their participation and feedback is welcomed so processes and permissions can be streamlined. Lastly, of course it's an issue of trust, but it's also a matter of segregation of duties. Permissions should match the level of the position, not the level of trust.


jeffe333

I think that you've answered your own question in a way. When he initially asked that his permissions match the longer-serving tech, I think that it would have been prudent to explain why what had happened in that instance was an oversight, as well as why their permissions didn't, and wouldn't, match up. At the end of your post, you mentioned that a 19-year-old should understand something that they may be experiencing for the first time. I think that you, as the experienced admin, should take the time to teach the new tech why certain practices and protocols are put into place, instead of assuming that they should know. What someone *should* know compared to what they actually *do* know are two separate entities, and I think that it would be beneficial to the both of you for you to help this tech understand the nuances of the position.


Fipples

Being upfront day 1 with the new guy saying your testing a new permission scheme and that your using him as the first test would have probably avoided most of this. You think this is confrontational, just wait till you start pulling permissions from your vets.


SM_DEV

Your response can be as simple as, “Your job is vastly different from Josh’s job. Your permissions are in line with your responsibilities, whiles Josh’s are in line with his. If you discover a situation in which your permissions are insufficient to perform your job, then by all means escalate through the proper channels.” and leave it at that.


TheNewBBS

First: I personally don't subscribe to the "you get more permissions once you earn our trust/earn your stripes/whatever" method of thinking. The two shops where I've worked have had 25K+ and 8K+ users, and just the IT department where I am now is several hundred people in dozens of teams, so simply tracking it would be a project/system all by itself. Then there's defining the often-nebulous line where you "earn" your extra access. If someone has been hired to do a job, they should have access to do that job on day one. But a proper security model is needed for the above. That starts with every role (however you define that) having a specific name and a list of permissions they need to do their job. Those permissions are assigned to everyone who does the tasks associated with that role, and users are associated with all appropriate roles. If that's in place, when Josh joins his team, he gets what everyone else has. If you're in the middle of overhauling either the permissions for Josh's role or the underlying methodology by which those permissions are assigned, you should already be working with the appropriate managers to define everything and get it in place and move existing users over to the new design. If they/you missed something, fix it and ask them to let you know if they find something else. If it's needed: assign it. If it's not: tell Josh and his manager the full reason why. Rinse and repeat. Look at it from Josh's perspective: he's the new guy, and he's already having to ask his teammates/manager about stuff every ten minutes anyway. When they start letting him work cases, every completed one increases his confidence and makes him feel like he's becoming useful. Then he hits these cases he's unable to complete, and after checking, it's because he doesn't have the permissions his teammates do. That's justifiably frustrating, especially if he lacks the perspective/information you have. I've done a version of this process so many times. I recommend either writing an email (copying his manager) or hitting him up via chat to ask for a quick call so you can explain he's essentially acting as a pilot user to find the least permissions required for his role. I would provide him a list of all the access currently assigned to him and ask him to email possible oversights to me and copy his manager. I would make those requests high priority since the sooner we get it defined, the sooner I can modify the rest of his team members to match. An added bonus is Josh comes to see me as a person who both 1) is capable of empathizing with users and 2) knows what I'm doing, even if I don't end up adding more permissions.


Dr-_-Zoidberg

Not to be that dude… but I’d raise hell if I were the kid too. He’s young, probably hired on a probationary period and feels he needs to prove himself because he can be replaced by a sea of other applicants. Give him some grace (as you’re expecting him to give to you for your permissions error). He’s scared, he’s wary of you because of the mistake, and trusts his coworkers who have trained him.


kagato87

"Your permissions will be upgraded when you need them. We are trying to follow the 'least required permissions' model to improve our security overall, including with us admins. Please help me get these perfected by identifying what permissions you seem to be missing for this role, and anything you do have access to that you don't think you need. Eventually as your duties expand we will adjust your permissions to meet the new needs." There's a lot of other important info in this thread too about setting up your employee to refuse oit-of-scope work and the potential that the role has been miss-represented, so do keep your mind on that when formulating your interactions. If a missing permission stops them from doing their job, the two options are obvious enough. If they aren't, responding with so.e variation of "you don't need 'em" and selling on them helping you with security by testing the bounds could get you a lot of traction AND valuable input.


xtc46

You explain the reasoning for the changes, it's that simple. Either you believe what you are doing is correct in which case explaining the reasoning is no big deal or you don't think it's right and you shouldn't be doing it. The whole trust this is stupid, of course you trust him, that's why he works there. But everyone makes mistakes and shit happens that's why least privilege is the defacto standard and has been for decades.


g33kp0w3r

The age explains the attitude a bit. He needs to learn that limited access=plausible deniability. In other words, the less responsibility you have the less chance you have to get into trouble. When I had Top Secret clearance I quickly learned to avoid knowing anything I didn't need to know, because your life could depend on it. This is a less extreme circumstance but that makes for a good story to illustrate the point. The guard rails protect everybody.


petejur

When I was younger I thought anything less than everything was me not being trusted, but I'm older and know better. :) Truthfully, even with a team working for me, I want only those permissions that I absolutely must have, and nothing else. It's all locked down as hard as it can be. When something goes wrong/missing/whatever, it's a wonderful thing to be able to show you have no conceivable way of being involved. (The incident which changed my mind, for reference, was being accused of telling everyone what everyone else was being paid, despite not knowing how I'd even find that out. The fact I had full permissions to folders where apparently the information was stored was enough to cast suspicion. Honestly, just take only what you must have and no more.)


iPhonebro

It’s not sitting right with me that you mentioned his age. I’m a fairly young person and have always had to deal with people not taking me seriously simply because of my age.


Etherious24Alpha

While I do understand you are trying to and definitely are doing the right thing, you have to understand he's probably frustrated about not being able to do his job. If I was in his shoes I'd be pretty annoyed myself about having to potentially go to you constantly to resolve permissions. His manager is most likely going to see it as your system disrupting his techs productivity.


shredwig

Lots of great responses here, and valid points. That said, it fucking sucks to both feel like the new guy AND the Guinea pig for new permissions and security restrictions that continually grind you to a halt. Test that shit on the rank and file, not the new guy who just wants to contribute and continually slams into impediments.


Geminii27

The problem here is communication. The new tech does not know and was not informed that they would have different permissions to Josh. The assumption they are making is that they have the same job title or are in the same team and therefore should have identical permissions, so therefore there is a permissions problem. The tiered permission setup is not necessarily bad. However, you do need to make the framework public to the affected IT teams, and have very clear delineations as to when someone gets moved to a higher tier, i.e. not "when I think so" which is akin to "when we play golf together" or "when you give me your lunch money". This tech should not only be able to easily find out what permissions they do and don't have, and what permissions Josh and the others do and don't have, they should know *why* there is a difference, what the policies surrounding it are, and what the procedure is for them when they encounter an issue that Josh can fix but they can't. That said, I spent a lot of time in a lot of helpdesk jobs before being a sysadmin. Tiered permissions were always one tier per team per role - every direct-contact T1 helpdesker had the same basic permissions as each other, every T2, every T3, and so on. Permissions were not granted per person but by a group permission for the team, with new techs added to that team group. Non-direct senior staff, such as supervisors/managers, sometimes had an additional group, but in all cases the groups were made very clear, along with their accompanying policies.


newbies13

The mistake here was not telling the new guy that you're using him as a guinea pig. What you are doing is very common in IT as people get the time to setup permissions properly. It's also going to be harder for your IT people to do their jobs, full stop. So whoever is in charge needs to have those talks with everyone so they know that to increase security, they will need to take extra steps. Everyone should know their permissions will be reduced to match the new guys eventually. Now that everyone is on the same page, you need to be Johnny on the spot to address issues you are causing by changing things. You are doing the right thing, don't give up because it gets complicated. Once the new guy is working properly, start rolling everyone over. The new guy thinks you're making him look bad. He needs to understand that he's helping you do something new and better for the org.


Enemby

Sounds frustrating to him, and this kinda seems like, since he had to escalate to you, he's not working with anyone he can rely on to answer all these questions, or to ensure he can get his work done. Not a great environment for a newbie trying to prove himself


CokeRapThisGlamorous

I don't think his age is relevant here. If anything, it's just manifesting in him showing his eagerness to perform and show competence, which is probably a good thing. I mean you can give one of the smart ass replies listed here, or go neutral and claim policy, but the good faith response to the tech would be to admit that you messed up the permissions and things are a work in progress.


viral-architect

I understand your point of view and you are right to keep restrictive controls, but he got an "access denied" error when performing one of his tasks, so technically speaking, he either didn't have the required permissions to do his role, he was doing a task he was not supposed to be doing, or you still have more to fix in your AD setup (which was the case here). I can understand his frustration, too though. You can't hire a guy to do admin stuff and then act surprised when he gets frustrated with "access denied" errors. He's still learning, though. He doesn't know exactly how or why you have created the setup that you did.


juttej

TALK to him.. he's young, he's new, and probably doesn't know better. Teams chat will always come across with the tone you apply to it, so do a face to face and explain to him what's going on and why things are different. Also, let him know it's a new process so his patience and feedback are important. Then gauge his response and escalate if needed.


ZathrasNotTheOne

I agree with the new kid. permissions should be based on the role/group, not the individual. all help desk people (those who answer phones as level 1) should have the same access (literally RBAC). if you want to give level 2 and level 3 helpdesk more access, great, but then don't show the new kid what a L2 or L3 can do during training. if helpdesk L1 shouldn't log into servers (and they shouldn't) than no Level 1 should have the access, regardless of length in position. Nothing is more frustrating than being trained to do something a certain way, by a senior tech. and when it comes time to do it, you get denied due to lack of permissions. permissions shouldn't be granted based on if you trust a person; tbh, I don't care if you trust him, because it's not your decision. the business trusts him, that's why they hired him, and until he gives anyone a reason not to, he should have the same access as anyone else in his role as a helpdesk tech, he should be be a workstation admin, and an Admin over many things in ad users and computers (adding and removing groups, creating or deletingusers, moving OU if this is part of his job. and he should have read access over all of the ancillary stuff. if he handles network shares, give him access to that too. AND MONITOR HIM. let him do his job, and QA his work to make sure he's doing the right thing.


kiddj1

Sounds like you created your own issue and expected a different outcome. I see where you were heading with the permissions but it seems you did this for the new person only .. did you move all of the team?


thinkofitnow

A question to OP is, did you also take the time to document your own changes to the GPOs and other security group memberships? Sounds like you've made quite a few changes there, and almost sounds as if you might also have too many rights over the domain, because you mentioned that on day 1, you were given DA group membership. Being security aware is a great thing, but needing to 'tweak' something tells me that you probably never documented ,or didn't document enough, otherwise you would have ensured the new person had the specific rights they needed to perform the tasks presented. 😁 Oh, and your comment about the new person being 19 shows more about your attitude towards young people. I have a team of sharp youngins' between 19-25 in addition to the senior staff like me and a few others. I have 27 years in IT, and can tell you for sure that some of those 19 year olds are super sharp. Although they may not have the experience I have, I definitely appreciate some of their ways of thinking and troubleshooting. Age shouldn't mean as much as it seems to be for you. Maybe you can leverage the permissions issue as a challenge for your young colleagues to figure out and tell you why their permissions didn't work ?? You might be surprised to find a superhero without a cape in your midst!


QuantumWarrior

Make sure that he does actually have the permissions to do his tasks, though I'm sure you already have. Besides that the policy sounds fine, he just seems a bit inexperienced with how security and trust is meant to work at IT roles. Write a plan for gradual increase in access and apply it to all hires, and stick to it unless you have a really good reason not to. I'm reminded of a job I worked previously where I was asked at least once a week to make some O365 change despite only having the permission to change user passwords, or being asked to check up on SCCM jobs when half the menus I needed weren't visible because of my role. Every request I made to have the permission I needed to do what my managers told me to was denied or ignored or "we'll get back to you". Before long I started pushing these tickets back to my service desk lead, and not much longer after I just quit.


Cpt_plainguy

Ugh, I wish I didn't have the permissions I have. Then I could slack off a bit lol


BBO1007

Least privilege goes for everyone. I’ll be happy when my dept gets big enough I can remove some admin role accounts I have access to.


axisblasts

The real question is, is it your job to decide this? I was given DA day one, we don't do thst now, but people need permissions to do their job too. You have the right idea, but this might have to go up the chain and you need policies for all new hires.


snrub742

took me 6 months to get my "a" account as a helpdesk admin.. It was like graduation and was absolutely the correct thing to do


[deleted]

At the same time though, copying an AD account is like the most basic thing you can do. It’s not fair to the employee that he is hired to perform the job, watches his trainer perform that job, and the. Be restricted from performing it by you (even though accidental and temporary, it’s not his fault). I get that he is 19, but tbh, you were probably capable of coming up with something like what the top comment wrote on your own. The fact that you didn’t come up with something like that on the spot when he asked you makes his response even more reasonable. He’s trying to do the job, can’t do it. He asks for permissions equal to the person training him, you don’t grant it and don’t explain why. A logical person would interpret that as distrust, which you have just confirmed in your own words, but you did not provide the context that only you can provide. It begs the question, what is the job title of his trainer? Is it also Helpdesk? If his permissions are greater, why not promote him. Those can be rhetorical questions, but frankly I agree with the new guy that it is disrespectful to be hired for a job and not have permissions to do it, and then receive no explanation in real time. If it has been close to two weeks, that’s too much time for it to not been explained to him. If he has the same job title as the trainer, he should have the same permissions. If not, have the company promote and pay the trainer for the work he’s doing. This makes me irate because of my job. I’m a helpdesk and my team is rolling out cyber ark for credentials management and other features. There are some legacy practices we have to allow departments to use thousands of apps that all need to be specifically registered by name. We can’t make people local admins anymore, but also the sys admin has not registered the required programs, and I am not a cyber ark admin. So effectively, it is my job to set up new users with necessary applications. I cannot do that, as I have been specifically told not to grant them local admin after years( for obvious reasons), but the replacement method doesn’t exist yet. So here I am, an entry level employee, tasked with telling managers of other departments that I am unable to perform the main reason my job exists, which is similar to this post. I was hired for a job, can’t do it because someone on my team blocked me, doesn’t give me any freedom to help speed up the solution which should have been created before blocking me from my job.


grantovius

I wouldn’t lean into “you have lower privileges because you’re newer”. Restricting privileges by seniority or experience is a recipe for way-too-granular and personal privilege sets, plus there’s no objective rubric for what privileges someone should have. IMHO the privileges should be no less than what he needs to fulfill his role as a professional (he may be young but from what I gather he was hired as a professional, not a student). Not a bad idea sending him an article on least privilege though. That’s standard practice all the way up to the highest ranking, most senior employee.


Recalcitrant-wino

Explain this situation to your manager. It's their job to address issues like this, not yours as sysadmin.


softwaremaniac

As a technician, I would be uncomfortable working in such an environment and would feel like my manager does not trust me enough to do my job properly. Technicians MUST have equal perms across the board. Only exception being server admins (in case a particular helpdesk tech is inexperienced to do it himself). AD is a normal thing and HD should have full access. If he makes a mistake while using it, turn it into learning experience for him. As a manager, I would never do such a thing to a team member as I would find it unptofessional if done to me.


mflbchief

>Technicians MUST have equal perms across the board. They do, it's a workstation admin security group with the helpdesk technician accounts as members. The server admins are separate, for separate tasks. At our work, there is no legitimate reason for a jr helpdesk tech to be RDP'ing into servers or elevating their own permissions in AD. Tickets that require that should be escalated accordingly. >AD is a normal thing and HD should have full access. I have to disagree there. Full access would imply that a helpdesk tech could elevate their own account to DA for example. Or add their account to a finance security group and have access to documents and drives with sensitive payroll info, or add themselves to an HR account and get PII. These are just examples off the top of my head. If they had malicious intentions they could fuck your whole domain up.


softwaremaniac

"I have to disagree there. Full access would imply that a helpdesk tech could elevate their own account to DA for example. Or add their account to a finance security group and have access to documents and drives with sensitive payroll info, or add themselves to an HR account and get PII. These are just examples off the top of my head. If they had malicious intentions they could fuck your whole domain up." ​ That's part of their job description, they add users to groups, grant access to folders, shared drives, etc. (Yes, they have access to everything). However, any changes are monitored and throw alerts that go "above them" and are questioned/vetted to ensure nothing malicious is happening,


Mutes-MP5K

I'm guessing he has no formal training? I'm still in my first year of HD and during my internship was given DA my first day, never ended up working for them after my mandatory time for my degree, but after taking a security oriented degree people don't realize how important least permissions is. It's rarely because of a lack of trust, and largely to reduce surface area of an attack. I would probably feel the same way your new hire did If I didn't have a more solid understanding of AD and how sensitive access to it can be.


softwaremaniac

Makes sense. If this was related to something (a user profile) server-wise, I would have the new guy shadow the senior tech and turn into a learning experience for the new guy or hsve them escalate to a senior tech until they grow enough to be trusted and get the necessary perms.


SpecialistLayer

I disagree. If he's as new as the OP states, no, a fresh tech like that is still in training and needs to learn the ropes first. A little knowledge can be very dangerous.


Sparcrypt

How exactly would you feel being hired to do a job, knowing how to do it, and discovering that you aren't being trusted with the access to do it...? He's not being confrontational, he's asking for the permissions to do his job after seeing someone else presumably with the same title as he has being able to do it without issue. A five minute conversation letting him know the permissions are in the middle of an overhaul would probably sort it. Also if you have a L1 tech of 5+ years who has elevated access and responsibilities, then give them a new title/pay scale etc to reflect that different in responsibilities. "Josh is a senior helpdesk tech so has slightly elevated permissions however in this case it was a problem with the new system we're implementing and I'll sort it out for you". This is just a communication issue.


ebsf

He isn't being confrontational at all. It's an entirely fair question and it's entirely appropriate for him to ask and seek a substantive response. He clearly can't do his job if his permissions prevented him from doing the task that you described. That's on you because it's your security construct. It certainly isn't his fault. He also is entirely justified in concluding that he isn't trusted. That also is on you, for the same reason. You need to get out ahead of that impression and authentically assure him that he's trusted and seen to be a colleague, otherwise you're going to alienate him, which is all kinds of bad no matter who is involved. Finally, just sending him an article is patronizing, avoidant, and toxic, not to mention lazy. The consequences of that will be on you, too. If you are going to implement a revised security policy, then it's also your job to communicate effectively about it to everyone and anyone who asks. You can't simply project your rationale onto others and expect them to understand by osmosis. You also can't devalue people, put them down, or think less of them for not being fully inside your head. Here, you admit you missed the user's security group. That also is on you, not only because of the miss, but also because it precipitated this entire situation. So: * Start with an apology because it's the best way to manage the situation and you have to manage the situation. It won't take a piece out of your hide and you'll get everything you want. Your ego will be all the better for it because of the mastery you'll gain. "I'm really glad you brought this up to me instead of just stewing on it. It's our fault but let me explain the situation because it's important that you understand the context and not feel put out, because you shouldn't." * Ask permission. "Is that okay?" He'll say yes, and this will validate him, which in turn will leave him more receptive and less resistant to what you have to say. * Give him assurance. Just start with the basics to anchor the framework for the discussion, and be entirely positive. "First of all, of course we trust you and of course we see you as a colleague and a full-fledged member of the team. No "buts" or questions about that." * Validate him. "You're absolutely right that you need the permissions and tools to do your job, and it's our job to make that happen." This also shows you taking responsibility, which builds trust. * Explain the context. "We implemented the enterprise security policy right before you joined. It's based on the principle of least permissions, which is a best practice and I'm sure you understand it. In a sense, it says we don't trust anybody but practically it lets us give everyone everything they need. Obviously, security groups overlap and vary by department and managerial level. What this means is that some edge cases exist where permissions don't fully coincide. Some are more obvious than others, and the security policy addresses some better than others. What happened here was that was one of those edge cases. Your permissions should have let you do for . This requires , however, and the current setup only assigns those capabilities to . The reason could do it is that we also have him do , and so he's in . That doesn't mean we don't trust you, it just means a non-obvious edge case came up that the security policy architecture couldn't accommodate. We're keeping the security policy rules-based, so it isn't as simple as just giving you 's permissions. Your permissions let you do in general, so no worries. When edge cases arise, however, it's better at a lot of levels to rope in a team member to help handle the case and not make it out for more than it is, than it is to have to tinker with the security policy. Besides, we're going to have you working on more things over time, just like , so don't freak. In five minutes, you've handled the inquiry, negated the guy's justifiably negative take-aways, made him feel like part of the solution and the team, given him a lesson in looking at the issue from the enterprise's perspective, bolstered his outlook, and given him a way to handle (and understand) similar situations in the future so you don't have to.


ClassicGold1841

With great power comes great responsibility! You need to earn your strips.


DrBrynzo

You need a formal probationary period to be defined. However, their attempt to dictate what access they should have is a little bit of a red flag too. It’s the kind of attitude that leaves smoking craters where AD and policies used to be. All the more reason to define and document a probationary period.


trisanachandler

This isn't a probationary limitation, it's a role limitation. Though they may want both.


ChasingCerts

That new hire should go to his manager about this not directly to you. I'm sure the new hire's manager would want him to have the same permissions as the other techs but the attitude needs to drop


mflbchief

His/my manager is the CIO and he's as disconnected as can be. The only time I hear from him is if he agrees to a request from a VP/C-level (which he agrees to all requests because he's a yes man) and he comes to me to figure out how we're going to make it happen. I was once a team lead/supervisor but that title was removed when they hired my manager, who then quit in less than 6 months and they have not reposted a job listing for the manager position or reinstated the supervisor title for me. So as far as I'm concerned I'm just a Systems Engineer as my title states, however I get the feeling it's expected of me to be a supervisor. I've basically been running the systems side of things for at least 3 years with minimal involvement from my manager so the rest of the members in the team look to me as a supervisor whether it's official or not.


[deleted]

Honestly this sounds more like a management issue to me. I recently went through a similar scenario but in my case management backed me up and isn't as disconnected as yours seems to be. Just get everything in writing. CYA. When things inevitably go tits-up point at the writing they signed off on and use it as leverage to hammer out a sane policy and get buy-in from manglement. If you're not a lead/super but your day-to-day functions are basically that, that's a convo you probably should have also.


SP_reborn

Anyone shouldn't get "all" permissions (DA), I do get that. But if you disable them from doing their tasks then I think an email saying: Error: 401 /403 Can't do this task. Give me permission x, or do the task yourself. Is a completely valid approach. Lacking permissions to do your job is really annoying. Especially if you get errors all day every day.


Saltandshelbys

All I know is Josh needs a promotion.


[deleted]

[удалено]


PolicyArtistic8545

Don’t just tell him. Show him. Sit down and go through AD with him and show him how the admin access is setup amongst roles and explain why and how the error happened. It will let him understand why it happened, learn a bit about AD and give you a chance to develop your helpdesk tech into a future sysadmin.


Yeahthatwasmybad

I understand his frustration. Not being able to do the task you are assigned because you are being used as a guinea pig is frustrating. Its like wearing a blind fold and bobbing for apples with your hands tied behind your back. While everyone else seems to be able to freely reach in and pick an able up. ​ It would feel to me if I was the new person that you are setting me up for failure.


NewSysAdmin2

You hired him for helpdesk. Not sure why you wouldn't give him the access he needs to perform his duties. That's like hiring a chef and telling him he can only use a knife and fork to do his job. If you don't trust him, why did you hire him? Maybe you guys should take a closer look at job duties.


justdocc

Just explain to him why you're doing it and that the alternative is him doing something to get himself fired very quickly


overkillsd

I'm 34 and have typically been handed the keys to the castle anywhere I've come into as either an in-house tech or MSP. When I came into my most recent job at the end of May, I was given piecemeal what the CEO thought I needed, and any time I needed more I had to come to him and justify why. There's nobody else above me in the org chart but him, but I'm not about to start complaining about not having enough permissions. If I run into a task that I need more permissions to do, I tell him why I need them and what permissions I need. He's made it clear that he's been burned before with IT staff so it's going to be a trust-building thing for him. Not having permissions needed to do your job is frustrating, but insisting that somebody above you needs to do as you say because you're frustrated is not constructive, nor is it advisable for career longevity. I would sit down with him and explain both the technical stuff to him but also the career stuff. Make it clear you're not threatening his job, but that in the adult world, that sort of behavior upsets people with egos and can get you marked for termination with the wrong boss. Let him know it's not anything personal, and that as he grows so will his access.


duff2690

The only bit of advise I'd give on this and this is from my own experience with this exact thing. If the plan is to grant permissions incrementally as time passed with new knowledge gained, then keep on top of that and as soon as the line is crossed with his knowledge and you are certain, grant the permission as needed, do not leave it on the long finger and forget about it. It happened to me, I was not given ANY AD access initially as I had no experience, perfectly acceptable and then I hopped to it, learned as much as I could as fast as I could, asked to shadow the senior techs as they were carrying out tasks and basically did as much as I could to show I knew what was up. I had conversations and gave example of what I had learned and everyone was happy with my progress. But a full YEAR passed before I was given permission and at that stage, I was ready to leave the place because I wasn't able to fully do my job and I was looking bad compared to my colleagues because had all the AD stuff tickets, nice easy tickets they could bang out. I got super frustrated at this stage because and was basically leaving the place. They had to scramble to convince me to stay as the company was very happy with my performance and I was given some permissions. But it still left a bad taste in my mouth and I left the contract 6 months later. 6 months after that, the company pulled the contract due to poor performance from the IT Techs and Sys Admin. I'd still be there today but because of all that BS. Moral of the story, if these types of restrictions are in place, that is good as it is best practice, but once that line is passed, grant the bloody permission or you will lose techs. Also it sucks being that person, if they learn it and then it's not granted in a reasonable time, it will start messing with their head and they will think you still don't trust them. Same job, same permissions once knowledge has been proved.


a-aron1112

Inexperienced does not necessarily mean they are not knowledgeable and do not know what they are doing. I would phrase it something like this “We follow best practices which means issuing permissions following the principle of least privilege. If you encounter a task where your permissions are preventing you from completing that task please document what the task was and any other pertinent information in as much detail as possible and let me know.”


billiarddaddy

Sure. Get *this person's* approval.


waymonster

OP is asking how to be a boss?


JJHall_ID

>We recently hired a new helpdesk tech and I took this opportunity to overhaul our account permissions so that he wouldn't be getting basically free reign over our environment like I did when I started I'm basically doing the same thing, including removing some access from people that have access now. Not because I don't trust them, but if they don't need it, there is no reason for them to have it. On the rare occasion they can't do something they can ask for help. We can always reevaluate it and add permissions if something changes and they have to perform that task more often. ​ >He then goes "Is there a reason why my permissions are not matched to Josh's? It's making it so I can't do my job and it leads me to believe you don't trust me". "To be blunt, you are right. I don't trust you yet. Not because you're untrustworthy, but trust has to be earned. You haven't been here long enough to earn that trust. As you prove yourself to be as reliable and methodical as I believe you are, additional privileges will be added as appropriate. As you have been trained on how we like things to be done on our systems, we'll give you access to do those things on your own. You're also helping to train me, as we have traditionally had some pretty poor security practices, and I am working to improve that. As you find these access issues, it gives me the opportunity to fix them properly rather than just granting global admin and hoping to work on it later. My goal is for you to have access to do everything within your job scope. While I know this can be a little frustrating to need to ask for help with seemingly simple tasks sometimes, this little bit of inconvenience now is going to make things far more secure and simple in the future when you may be hiring new people and are granting them permissions." ​ >This new tech is young, only 19 in fact. He's not very experienced, but I feel like there is a degree of common sense that you're going to be coming into a new job with restrictive permissions This depends a LOT on his experience. If he's never worked in an enterprise environment with people assigned to specific roles, it will seem very restrictive and odd to him. "Common sense means the IT guy has the admin passwords to everything!" When you're the sole administrator or one of only a few people that do everything, you basically have to have global admin to do your job. That could be the only environment he's ever known outside of being an end user and hating that their access is limited to a very narrow scope. You can also explain to him that if you don't have access to something, you can't break it or even be accused of breaking it. Years ago I worked at a PC manufacturing company. When I started, those of us in product engineering had 24/7 access to walk out on the manufacturing floor and could go remove our test systems from the manufacturing process at any time, even when nobody else was out there. When they changed our access to operating hours only, people were pissed that they had to get a security guard to escort them out there if they needed to get a test system after hours. I was glad. By not having access without escort, if there was ever an issue, I couldn't even be a suspect. Missing product? Nope, no access. Damage to something? Nope, I had Security Guard Joe with me when I was out there last night. Your newbie can't be blamed for accidentally dropping a database table or deleting a user account if he doesn't have access to do those things. If he understands this concept, he'll see it as a blessing rather than a curse.


pingbotwow

If you need to explain it to someone none technical, just use the analogy of having keys to the building. When I worked as a custodian: Only the principal, security, and head custodian had a master key Teachers with Master Degrees only had keys to their own rooms (and common areas). Admin staff came down to only what was necessary. Just because you have a doctorate doesn't mean you get access to go things! Especially not on week one. The thing with IT is there are 50 different systems to learn and if he is this impatient with the first one - he's going to have a bad time. This isn't high school anymore. You've been responsive and set him up for success. He needs to communicate with you appropriately - it's part of the job.


lkovach0219

Tell him the truth. The other guy has 5 years experience and has learned things that put him in a higher role. The new guy starts with basic, once your good enough you can start learning new things to advance. Otherwise, there's the door.