50

Somehow related to this other question. I am dealing with the following case: a medium-large company (with about 200 on-premises employees) is applying the following procedure for all the newly recruited employees (immediately before their first day at the company):

  • they generate a password for the user (NOT a change-at-first-login one)
  • they login on their laptop (impersonating the final user)
  • they apply some configuration (e.g. they access their Outlook email in order to check that everything works)
  • they change again the password (this time with a change-at-first-login one)
  • the laptop is delivered to the user

It appears that this procedure is quite common also in IT companies.

I cannot say if the initial configuration, "in the name of user", is absolutely necessary or just dictated by convenience reasons (a fully working laptop is delivered to a non-IT user, preventing a lot of requests to the IT for fixing common issues), but there a few things that smell:

  • if I should never tell an admin my password (as it has been answered to the cited question) there is no reason that an admin knows my password even at the very beginning of my work in that company
  • I can accept that an admin knows my password (when he first creates my account or when he resets it) provided that it's a change-at-first-login password (so that I have evidence that it's not been used before). I suspect anyway that most legacy systems (like AD) allow admins to reset passwords with great freedom (for example resetting passwords without notifying the user, or without forcing them to set a change-at-first-login one). Is it an accepted practice? This seems completely different from what happens for example in Google (no one knows my password, if an activity is detected I am notified).

Edit: to answer many comments that state that "the computer is not yours, it's the employer's computer, you should not have personal information on the company computer" I would like to point out that it's not a matter of personal information, but reserved information regarding the company business. So, if it's correct that I should not use my company email to receive my blood analysis results from my doctor, it's perfectly common that some reserved information about the company is exchanged between employee A and employee B.

Diego Pascotto
  • 601
  • 1
  • 5
  • 5
  • 27
    When the computer is joined to the domain and has MDM software installed, the domain admins can always change the passwords and depending on the setup they can also read and edit all the files stored without logging in as the user. As long as they don't know a password the employee might be using elsewhere, they are not gaining any more access here than they probably already have. – J.A.K. Nov 21 '18 at 10:31
  • 1
    J.A.K., so the only reason for not telling an admin my password is that he could gain access to another system (if I use the same password for my bank web access, let's say)? – Diego Pascotto Nov 21 '18 at 11:09
  • 8
    No - once data has been associated with the account, they could gain access to it without this being logged as admin access. In the scenario above, logs would show the generation of the change on first use password, and actions prior to this could be attributed to the admin. Actions after the password has been changed could similarly be attributed to the user. If you told the admin the new password, that attribution in log files would no longer apply. Another risk is that it's not actually the admin asking - a genuine admin won't need the password in a sensible system. – Matthew Nov 21 '18 at 11:17
  • 1
    @DiegoPascotto No. As I said in my answer this rule is made because admins should not access your confidential data associated with your account such as mail. There is no associated data on the account at this point. – Kolappan N Nov 21 '18 at 11:19
  • 1
    @KolappanNathan But they can access the 'mail... They can't without evidence in any sane system, but the sysadmin could almost certainly access the data required to reconstruct the inbox. – wizzwizz4 Nov 21 '18 at 21:46
  • 12
    @wizzwizz4: As a sysadmin, I can read any data while leaving zero evidence from the production systems. Let this sink in. As sysadmin, I have capacity to alter the OS and erase log entries at will, but I need do none of that but only become the backup agent and read files at will. – Joshua Nov 21 '18 at 22:44
  • 1
    @wizzwizz4 unless you outsource your mail system to a third party, there's always going to be a someone that works at a level that can access the mailbox without leaving any trace of evidence you can see (or who can tamper or disable the logs if they wanted to). If you outsource to a third party, that sysadmin just don't work for you. The only way to protect against this is to require client side encryption for all emails, though this will still leak metadata (who sends to whom and when). – Lie Ryan Nov 22 '18 at 03:05
  • @Joshua Surely there should be a log of all commands, including the "disable the log" command, sent to a protected server that you do not control? – wizzwizz4 Nov 22 '18 at 07:09
  • 7
    For those that argue about automation - you probably live in a dream-world. At least since Laptop-Vendors startet to use different hardware depending on pricing for the same laptop series, there is no guarantee an image will run on another laptop with the same config. Andere there are a myriad more pitfalls, where a certain username, windows update, combination of roles, ... could lead to new problems on the "same" hardware with the "same" automatic config. – Falco Nov 22 '18 at 10:57
  • 3
    @wizzwizz4: I'm not so silly as to disable the logs by running the command to disable logs. It's more like "started mmc.exe with elevated token". – Joshua Nov 22 '18 at 15:51
  • 2
    Very very very big issue. There is rarely a setting for "change-at-first-login". It's "change-at-***NEXT***-use". In windows, your main password scenario, you as the end user would not know if someone previously logged in with that password. An admin can set that on your current password tomorrow and you wouldn't know. – cde Nov 23 '18 at 07:18
  • 2
    @DiegoPascotto with regards to your edit. when the sysadmin was hired part of that was trusting them with the kind of information you describe. because the guy setting up your systems or the guy running your network or running your emails could steal everything anyway, they were hired on the basis that they just wont. – J.Doe Nov 23 '18 at 09:54
  • Never impersonate a user. After creating an account for a new user it is standard practice for a new user to log into the assigned hard, software, accounts. When doing that the profile is created on the computer. Of course the sysadmin should set the user to change the password after successfully logging in for the first time. Anyways, it is important for the new user to setup their settings, configurations, customizations, etc. when they log into everything. The CIA triad (confidentiality, integrality & availability) is immediately violated when you impersonate a user. – rockower Nov 23 '18 at 16:57
  • 1
    What's the concern here? "Hey why did Nick the new guy delete the prod database? And why did he do it two days before he started working here?" – corsiKa Nov 26 '18 at 02:11

10 Answers10

90

If I should never tell an admin my password (as it has been answered to the cited question) there is no reason that an admin knows my password even at the very beginning of my work in that company

One of the main reasons to this rule is that Admins should not access your confidential data such as mails, etc... Since there is no data associated with the account at the very beginning this is not an issue.

they generate a password for the user (NOT a change-at-first-login one)

Using a single sign-on password will ask for a normal password before one can change the configuration. So a password is needed before accessing the config.

I suspect anyway that most legacy systems allow admins to reset passwords with great freedom. Is it an accepted practice?

This is an accepted practice. Not old systems but newer systems like Office 365 also allows the admins to reset the users password without notifying the user. However any such resets gets logged in the system and the admin will be held responsible for any issues.

Also note that not all configurations can be changed at Admin level. Some things can only be performed by the user. Instead of telling each and every user to perform a set of steps, they are doing it ahead of time.

Some other concerns of sharing a password do not apply here such as

  1. Reusing the password is irrelevant as the password is not yours.
  2. None of your personal information is associated with the password.

To answer some comments,

I suspect that "there is no data associated with the account at the very beginning" it's not absolutely true: I could have some emails in my mailbox (someone could have sent my some confidential info to my email address, because the mailbox has been activated before I first log in)

by Diego Pascotto

Mail Id should not be shared to anyone by the Admins before configuration. The mailbox must have been activated when setting up outlook. Email Ids are shared only after single sign-in password is set. Also as pointed out by James Snell, receiving an email within minutes of account creation is unlikely.

A competent company has images, procedures, via automation that take care of these things without ever logging in as the new user at any time.

by Sokel

Small companies do not always invest in automating. If a company hires around 10 staff per year and each with a different role the effort required to bring automation and maintain it will be greater than the manual effort. Automation is only worth the effort when you are having job that is done repeatedly in large numbers. In other words, the effort required for automation should be less than what your effort required for manual work

If the admin has had unmonitored access to your account at any point in time; they could've set up anything under your name - preventing any returns to them.

by UKMonkey

Any actions taken by the admins during this time can be linked back to them as it is clear that the account is not handed over to the user until the user resets the password using the single sign-on password.

Kolappan N
  • 2,662
  • 14
  • 26
  • Ok, I see the point, but I suspect that "there is no data associated with the account at the very beginning" it's not absolutely true: I could have some emails in my mailbox (someone could have sent my some confidential info to my email address, because the mailbox has been activated before I first log in) – Diego Pascotto Nov 21 '18 at 11:36
  • 1
    @DiegoPascotto Your mail Id should not be shared to anyone by the Admins before configuration. The mailbox will be activated when they are setting up outlook. Email Ids are shared only after s single sign-in password is set. – Kolappan N Nov 21 '18 at 11:40
  • 1
    @DiegoPascotto - since they've probably only just set up your user account before logging in to check that it works it's unlikely. – James Snell Nov 21 '18 at 11:40
  • 3
    What do you mean by 'not share your email id'? If the company policy for assigning email address is name.surname@mycompany.com anyone can guess my email and send me a message before I actually log in . – Diego Pascotto Nov 21 '18 at 13:16
  • 4
    Notice he said the email account is activated when setting up outlook. Any emails sent to the address before that point will bounce. – Joe Nov 21 '18 at 13:50
  • 25
    Also mind: Generally company email are property of the employer, not private data from the employee and (depending on other agreements in employment contract, national law, worker council agreements, whatever) the employer (or their representative as admins) always have the right to access it. – johannes Nov 21 '18 at 14:28
  • 6
    The answer ignores a very common policy - what happens to your account is your responsibility. Accountability is 99% of the reason for the passwords; the company really don't care if the admin accesses your personal information - that shouldn't be on company PC's in the first place; and the admin can usually access all data on the network for backups etc. If the admin has had unmonitored access to your account at any point in time; they could've set up anything under your name - preventing any returns to them. So no; it's not ok for the sysadmin to have the password at any point in time. – UKMonkey Nov 21 '18 at 17:28
  • 1
    The only problem might be if the user changes their password and is told that the password has been used before, in which case the password used by the admins is leaked. So the admins better use a temporary password that is different from any password used elsewhere in the system. – Simon Richter Nov 21 '18 at 18:03
  • 15
    @UKMonkey But if the the admin is setting all of this up before the user has even been delivered the system, there is a record that whatever happened was not done by the user. Everything that was done before the change-at-first-login password was done by the admin. – David K Nov 21 '18 at 19:56
  • "any such resets gets logged in the system and the admin will be held responsible for any issues." What's more, the admin can't change it BACK, so, the user herself will know that it happened. – Beanluc Nov 21 '18 at 23:58
  • @DiegoPascotto `If the company policy for assigning email address is name.surname@mycompany.com anyone can guess my email and send me a message before I actually log in.` No one will send an email before they know that an account has been created. In case of such policy they know that this will be your email but they will not that it has been created until the IT department tells them. – Kolappan N Nov 22 '18 at 06:05
  • @KolappanNathan perhaps silly, perhaps realistic, example depending on the user: I know I'm going to get ChrisH@example.com because I've been told by my manager/that's the form of all email addresses at example and ChrisH is an uncommon name (hypothetically). I also know, because HR have told me, that I'll need to update my bank details on their system so I can get paid. So I email them to myself in work, along with a sharing link to my personal calendar so I can see family appointments, before I head in on my first day, but before. the sysadmin does the final setup. (Obviously *I* wouldn't) – Chris H Nov 22 '18 at 09:27
  • @ChrisH **You don't even know whether or not that email exists, you don't know its password.** You only know that this will be your email in the **coming days**. This email will be yours in the future but it is not yours yet. Unless you have received an info that you are assigned *this* email and *this* is your temp pass, you are not assigned any email at all. Why would you email your confidential info to such an email that is not yours? – Kolappan N Nov 22 '18 at 09:52
  • @DavidK Are you trying to tell me that a sysadmin doesn't know how to change the create/last edit date on a file? If they're even slightly good at their job, they'll be able to hide the evidence. – UKMonkey Nov 22 '18 at 10:24
  • 3
    For the email and "doing evil stuff under your account" - 1. An admin which accesses your hardware with administrative privileges could already install any backdoor/rootkit he wants. 2. There is a fixed time at which your account is handed over to you, only actions taken with the account after that time are your responsibility. – Falco Nov 22 '18 at 10:54
  • @KolappanNathan *I* wouldn't. Plenty of otherwise intelligent people would (I work in academia, where people are clever but fairly trusting and in most cases ignorant of security). I had to tell the tale in the first person to fit the character limit. – Chris H Nov 22 '18 at 11:29
  • 9
    @Sokel If automation is 100% always worth the effort, I assume you, personally, have already automated your car (if you have one) to be self-driving? Created an AI to respond to all your emails automatically? Automated your entire job? You've built a machine to shampoo your hair for you while you're in the shower? Or perhaps you've decided that some things would be too time consuming (perhaps to the point of impossibility) to automate and make strategic decisions based on the time, complexity, and failure modes of a task about when to automate and when to do things manually? – Zach Lipton Nov 22 '18 at 21:06
  • 8
    @Sokel: I work at a company with 7 employees and have only hired 1 person in the last two years. Are you really going to tell me automation is always worth it? Do you assume we have an entire desktop/IT support *team* and not just a single employee that does that stuff now and then? Not everyone works at a massive corporation. – whatsisname Nov 23 '18 at 06:16
  • 3
    @Sokel Automating the process of adding a employee involves integration with Email providers, Active directories, services like Slack, task management, code hosting, etc... The account should integrate with only required services. These automation break with any changes in any of these service or when a new service is added or replaced. in addition to Windows / Mac / Android OS changes. Also note that Windows update cycle is bi-annual now. I clearly understand the benefits of automation but **the effort required for automation should be less than what your effort required for manual work.** – Kolappan N Nov 23 '18 at 06:38
  • 3
    @Sokel [Ah the old automation fallacy](https://xkcd.com/1319/). Nobody here is arguing that automation isn't worth for larger companies. But the simple fact is that small companies don't need this very often and don't have the expertise in the first place. Which means it's simply a very bad ROI. – Voo Nov 24 '18 at 20:26
  • 1
    @Sokel You failed to respond to either Kolappan's or Voo's actual arguments. Simply pointing out the existence of technical debt and automation does not address their concerns. When the time and money spent on automation is greater than the time and money spent on the manual process, automation is stupid. Period. – barbecue Nov 26 '18 at 15:34
29

In a small company, it is likely that the administrator that sets up a new employee's machine is also the administrator of the company emails and document servers. In which case, the admin is already able to read your emails or send an email as you at all time without ever needing access to your machine.

If this is the case, then there is no new security issue here, although it's true that the practice is kinda superfluous. In theory, an admin should never need to login to your account using an active password; they can login as administrator account instead and pretty much do anything they needed to do from there.

In practice, unless your IT team is well practiced enough to be able to set up new machines repeatable, correctly, and reliably every single time, it is often significantly easier to login as the user to test setup and do some configurations that are just easier to do as the actual user rather than trying to simulate the effect while being logged in as the administrator. Many enterprise systems are designed to allow admins to be able to reset another user password or impersonate another user without the user's password, often this is logged to allow auditing, but in smaller companies, the same admin likely also have access to the system where they can tamper the audit log.

The main reason for the adage that "never tell an admin my password" is to prevent users from falling victim to social engineering, because if user are told all the time that a real admin never would actually need or ask your password, it becomes an automatic response that only someone pretending to be an admin would ever need to ask you your password. The secondary reason is that a lot of people reuse their password; in which case they may share much more than they realize. Neither of these applies in this situation.

Lie Ryan
  • 31,089
  • 6
  • 68
  • 93
  • "they can login as administrator account instead and pretty much do anything they needed to do from there." I've been specifically told by IT personnel that something about AutoCAD or some of its plug-ins made this impossible. Unfortunately, I don't know the exact details. – jpmc26 Nov 21 '18 at 20:26
  • 2
    @jpmc26: I know about it. Basically, to make AutoCAD work you had to install it with admin rights as the user who would be using it. The software wrote all kinds of stuff to HKCU during install. – Joshua Nov 21 '18 at 22:49
  • As an admin, my third reason to never ask the user for their password is that I compare it to handing me the keys to their car or home... Then they would have no proof that it was me or them that did something nefarious. – Canadian Luke Nov 21 '18 at 23:48
  • It doesn't really make it impossible though, an admin can modify another user's HKCU. Though it's probably just a whole lot easier to just let the software do it than to figure out which keys gets modified. – Lie Ryan Nov 23 '18 at 10:42
  • @LieRyan Let's just leave it at "prohibitively expensive," then, as trying to duplicate the logic of the AutoCAD installer (which probably changes by version) is an entirely unreasonable proposition. ;) – jpmc26 Nov 24 '18 at 22:44
  • @jpmc26 I agree – Lie Ryan Nov 24 '18 at 23:13
  • I like that this answer gets at the question of *why* admins shouldn't know your password. Often the reality of security has more nuance than the simple story we give clients. – Cort Ammon Nov 26 '18 at 02:50
18

I'm going to approach this question from a different direction.

Your question is based on the assumption that the account is the responsibility and/or property of the new user at the moment it is created, but that's not really true.

When the account is created, it belongs to the IT department, not to the user.

The initial setup you describe is happening before the new user takes possession of the account.

The fact that the account has the new user's name on it doesn't change this. The admin could create an account for Donald Duck, and then later change the name to that of the new user.

The user only takes possession of the account and becomes responsible for it when they log in and assign their own password. That's the hand-off of the account.

Suppose you order a pizza for delivery. The shop writes your name down and starts cooking the pizza. They could put the wrong toppings on it, or burn it, or drop it. Is this a security concern, because they have access to your pizza? No, because it's not your pizza yet. It hasn't been handed over to you. If the shop makes a mistake, they are responsible for correcting it.

Once you have paid for it and taken delivery, it becomes your responsibility. If you drop it, or throw it at your neighbor, the pizza shop is not responsible.

Regarding email concerns, if email is present in the account before the user's first login, it doesn't matter, because it's not his email yet. Email isn't secure anyway, it's easily viewed by any number of people. Also, in most jurisdictions, corporate email is the property of the company, not the individual.

barbecue
  • 589
  • 4
  • 8
  • However; if your company hands you a laptop which you can use for private usage, most countries have privacy laws in place to protect the user from being spied on by the company, even though they might technically own the laptop. You have privacy at work and you have privacy when you're not working. Following your theory, that means the company can just install RAT software because they own the laptop, then give it to the user and no harm done? – Kevin Nov 22 '18 at 00:33
  • @KevinVoorn: I was getting ready to answer in a similar vein with a simple scenario-the employee-to-be decides the job isn’t worth it, and never starts work.Now,there’s activity under a username that would have been used by him had he actually started work.What is the never-employed on the hook for?Nothing, because he never had access and didn’t do anything, and it can’t reasonably be alleged that he did.Same thing for things that happened before he started work. As for the email and privacy, turn it to the physical: he barged into my cube without a by your leave and rifled my filing cabinet. – jmoreno Nov 22 '18 at 00:52
  • 3
    @KevinVoorn the whole question of whether or not an IT admin could do illegal or nefarious things is irrelevant, because the question is about any inherent risks in the procedure described, NOT about any inherent risks in trusting IT staff. If your IT admins want to install nefarious software on your computer, they don't need YOUR login to do it. – barbecue Nov 22 '18 at 01:18
  • 3
    @jmoreno Here's a real-world example from my own experience. A user was hired for a position, an account was created, computer previsioned, etc. Shortly before he was to start, a positive drug test came back, making him ineligible for the job. At that point, the runner-up for the position was contacted,. She accepted the job immediately. The existing account that had been created for the first employee was simply renamed for the new employee. Neither employee owned the account yet. The account was still under the control of the IT department. – barbecue Nov 22 '18 at 01:26
  • @barbecue That is true, but I was giving another example like you did with pizza of why your logic has flaws in my opinion. I agree with the conclusion, just not the arguments that led there ;-) – Kevin Nov 22 '18 at 01:28
  • 2
    @KevinVoorn If you can be more specific about exactly what you see as a flaw in my reasoning I'll try to address it. I'm specifically addressing the question of whether or not there is an inherent security risk in logging in under other users' credentials before they take possession of the account, and I can't see any that don't also exist if a different procedure is followed. – barbecue Nov 22 '18 at 01:36
  • What you're saying is correct, although ``the computer is not owned by user yet so IT can do everything they want`` isn't true in all cases, that was my thought about it anyway. – Kevin Nov 22 '18 at 01:39
  • [One US pizza chain](https://www.dominos.com/en/pages/carryout-insurance/) seems to [disagree](https://www.adweek.com/creativity/dominos-offers-to-fix-potholes-in-your-neighborhood-so-carry-out-pizzas-get-home-safely/) (to atttract attention, of course) – dave_thompson_085 Nov 22 '18 at 19:55
7

Generally it recommended to use a personal account for everything you do. Logs will show who did what. That's why admins don't just all log in with "root" or "Administrator", but have their own accounts: you can tell who did what, and you can easily revoke the administrator's credentials without changing the password for all administrators.

Users have trouble choosing secure passwords. If they memorized a few strong passwords and use those for everything, you can probably consider it an above-average user already. If administrators know the user's password, they might be able to log into the user's private accounts (such as personal email, music streaming service, whatever). The administrator can always impersonate a user: they can reset the password, and often it's also possible to just log in as that user without knowing the password. On unix-like systems, you can run the command su john to log in as john: if you are a normal user, it will ask for john's password; if you are root, it will just log you in as john without needing their password. This is not recommended for the reason mentioned in the first paragraph, but it's totally possible on many systems.

The final piece of relevant information is that things are easier to configure from the user that needs it. If John needs Outlook, you can write a script and schedule it to be executed on first login. In smallish organisations, however, it might be more efficient to just log in as John once and setup Outlook manually. Windows in particular does not lend itself well for scripting: most of it is possible, but it's not well-established and some things are still accessible only through the graphical user interface (GUI).

In conclusion, assuming that this is the established procedure, I see no risk in it. The administrators can log in as any user anyway, so they are not gaining more privileges through it. They are also not learning the user's personal password. The only issue is that logs will briefly show activity under the wrong name, but I see no benefit for a malicious administrator: there are a thousand other (easier) ways to do malicious things.

Luc
  • 31,973
  • 8
  • 71
  • 135
  • 1
    From your answer i see that it is an accepted practice that an admin sets a password for the user and logs into a system as the user (I'm limiting only to Windows system). If a malicious admin then reads the user's emails this must be considered an acceptable risk (he is not gaining more privileges with that action). What about *sending* an email as the user? – Diego Pascotto Nov 21 '18 at 11:23
  • 5
    @DiegoPascotto - there's no reason to limit it to windows. It's perfectly reasonable for IT to check that the user environment works correctly before the account/machine is handed over to them. It's not usually necessary, but in a small/medium business like that it's hardly unusual. – James Snell Nov 21 '18 at 11:33
  • 4
    @DiegoPascotto In the answer I said "there are a thousand other (easier) ways to do malicious things". One example of that is reading/sending email on behalf of the user: the admin can already do that without logging in as the user. Either the admin logs in with their admin account and reads your mail file (e.g. PST file), or they look in your mailbox on the server side. Sending can be done using telnet. For malicious actions, there is no advantage to changing the user's password temporarily and then logging in as the user. – Luc Nov 21 '18 at 13:22
  • 5
    @DiegoPascotto *"If a malicious admin then reads the user's emails"* Wait what? Earlier you were saying it's a one-time thing when creating an account. Now you say there is email in the user's account, implying that the admin should not read it. If you change the question, you should not expect my answer to still match. Reading/sending email is different from finishing an account setup. – Luc Nov 21 '18 at 13:24
  • 1
    I'm not changing the question, it is actually a one-time thing. I guess it is not a frequent situation but it may happen that during this operation (the Outlook configuration) the inbox has already some incoming messages. In this case the reading (voluntary or not) of an email would be almost unavoidable (imagine the preview panel which is set by default). My question is still "is the configuration made by admin AS THE USER an acceptable practice"? – Diego Pascotto Nov 21 '18 at 14:27
  • @DiegoPascotto This may happen in a scenario as this: IT is informed that John Doe will start working in a few days and need to work on project X. IT creates the account, including mail jdoe@example.org. For some reason, the actual hiring of John Doe is postponed by a few weeks, but other internal (or prematurely informed external) members already send mail. Shortly before the actual date, IT checks setup once more. -- I'd say this is still the fault of the senders or in particular the persons spreading the (accidentally) false info about John Doe's status. – Hagen von Eitzen Nov 22 '18 at 07:37
7

is the configuration made by admin AS THE USER an acceptable practice?

Yes it is.

As with all practices it depends on the context. But generally speaking this is a common and acceptable practice, given that you have a basic level of trust in your admins and not a super high level of security need, like when you guard state secrets.

It is okay, despite the general rule, because initially your account does not contain sensitive data. While there is a short time-window where mails could come in, before you changed the password, this is typically so unlikely to a) be the case and b) contain really sensitive data that it is usually not considered an issue.

Note that many companies retain the right to access your mails and/or files on your work machine anyway. Though ethical companies will guard that access with either a requirement that you are present or that at least two admins are present when they log in to your account, to make sure they only act in line with their administrative task, e.g. remove a virus, look for a totally necessary file while you're on holidays etc. The same safeguards could be in place for this short time where they have direct access to your new account.

Note that you have to trust your admin department in general - they could simply install a corrupted system anyway. The risk of impersonation within the short time frame is minimal however, as it is clear from your contract and the timestamp of your initial password change, from when on you had control over your account.

Whether the practice is acceptable without further safeguards, e.g. 4 eyes principle, depends on the security needs of your company/job. The more crucial security is the more strict the safeguards need to be - and the more one would aim at automating these processes to minimize the window of opportunity for anyone to corrupt your machine/account or gain temporary access to your data. Note that the latter could also be achieved by simply having you activate your mail address once you reset the password.

Frank Hopkins
  • 637
  • 3
  • 6
3

Acceptable But Not Ideal

In order for this to be acceptable, it should be part of a documented procedure. This serves to explain the reason for the behavior as well as to preclude any accusations of impropriety.

Documents are generally approved when signed off or otherwise finalized, so this would also establish official approval of the practice.

Better Idea...

If there are actions which must be performed with the user's credentials, it is preferable to automate the process. The automation can take the form of a script, a setup wizard, or a self-service portal---whatever the organization prefers.

This provides multiple benefits:

First, the user interaction is minimized to prevent misconfiguration. Second, administrator "touch time" is reduced. Third, the configuration will not suffer from human errors or inconsistency between deployments. And, finally, your concerns about account use will be eliminated.

Caveats

There are additional skills required for automation (compared to manual installation), and your organization may not have those skills. Some platforms are difficult to automate, although this is less of a problem than it used to be. Or, the company simply may not understand the benefits of automation.

DoubleD
  • 3,862
  • 1
  • 6
  • 14
1

What the other answers miss IMO is:

Why isn't this process automated?

Provisioning of user accounts (no matter of the operating system) is nothing what an admin should do by hand over and over again. The initial configuration of a user account and provisioning of software can be done via automation. The setting of the user account's respective password would be done automatically as well. This should be "change after first use". This automation process has to be reviewed regularly and has to be implemented with a four eyes principle.

Everything an admin does on a machine should be logged. If an admin just roams freely on a system before provisioning, 'bad admin'-scenarios are bound to happen.

Edit:

As this answer has stirred up some conversation, let me add the following:

Here are the some tools to provision Windows images to company hardware, for Windows 8 the Microsoft Deployment Toolkit and the System Center Configuration Manager for Windows 10. These tools are official Microsoft tools, they are free (as far as I can tell) and from frist glance pretty well documented. There you can implement and document all processes for provisioning Windows 8/10 on company hardware easily. All admin accesses to a machine should be done via tools like these and should be logged with a logging server. Then there are less possibilities for a single admin to manipulate a single machine.

If an admin handles every machine by hand, 1) manipulation is possible and 2) errors are bound to happen. An automated process can be reviewed and audited, a manual process is impossible to control.

The commitment to tools like these is a step towards a more secure provisioning of operating systems and user accounts in a company environment.

Tom K.
  • 7,913
  • 3
  • 30
  • 53
  • How can the procedure such as setting up Outlook app on a person's laptop be automated? Also small companies do not always invest in automating. If a company hires around 10 staff per year the effort required to bring automation and maintain it will be greater than the manual effort. – Kolappan N Nov 22 '18 at 03:58
  • 2
    To automate a 10 minute system config process will take **far** more than 10 minutes, and will definitely require a much more expensive System Admin. If you get an incompetent Admin to do the automation, best-case scenario is it'll not work. Worst-case scenario is they open up every system to vulnerabilities. You also need a manager that can tell the difference and knows how to hire for automation. It is a much more expensive endeavor. Ever tried making a custom Windows install disc with specific pre-installed drivers? It took me several hours the first time... – Nelson Nov 22 '18 at 04:55
  • @Nelson I'm not sure where you are getting at? According to [this](https://xkcd.com/1205/) scientific chart(!), saving 30 minutes weekly (which I'm pretty sure that this task will take if I read OP right) one can invest 21 hours into this. – Tom K. Nov 22 '18 at 07:17
  • @KolappanNathan I don't know. I'm not a Windows Sysadmin, but I'm sure there's a way. – Tom K. Nov 22 '18 at 07:17
  • I can assure you 21 hours of automation will last maybe 1 month, then you'll have to do it again when new things come out. It's a lot more complicated if the company is not running a dumb terminal. Different departments, different software packages, etc. It is a massive amount of time, and it changes, at minimum, yearly, across every department. – Nelson Nov 22 '18 at 07:28
  • 1. I really don't think so. 2. Even if, so what? Just because things are hard, doesn't mean I want my machine setup by hand by an administrator. – Tom K. Nov 22 '18 at 07:41
  • 1
    @TomK. Have worked in large and small orgs for many years. You cannot automate everything. It can be a lot more efficient for the admin to do this by hand before the user comes in rather than walking the new user through the whole process on their first day. For a "new user experience" to hit them with a complex and error-prone process is a poor first impression. And they are admins, they have access to everything anyway. – schroeder Nov 22 '18 at 13:07
  • @schroeder 1. True, you cannot automate everything. But I am pretty sure that this is automateable(?) as it is done automatically in my company. 2. Every other access by an admin should be logged and should be accountable. If a laptop is handed to the IT department and a random admin handles it, nobody knows who handled which machine. – Tom K. Nov 22 '18 at 13:43
  • 1
    @TomK. except that the admin who does this would be known. "Tom was configuring new devices". And I'm not sure why there needs to be further attribution when there is no access granted or exercised. – schroeder Nov 22 '18 at 13:55
  • Edited my answer to clear things up. – Tom K. Nov 22 '18 at 14:42
  • Automation is always 100% worth the effort. Doesn't matter if it's a Linux or windows server or a Linux or windows workstation. You have automation in place that saves time. Yes, there's a learning curve, @KolappanNathan but once you've done it one time, that's it. You will now always be able to have repeatable processes and procedures and know what to do or expect, thus reducing any liability. – Sokel Nov 22 '18 at 17:48
  • "There you can implement and document all processes for provisioning Windows 8/10 on company hardware easily" spoken like someone who seemingly has never used either tool or had to deal with trying to automate the dozens of other tools that you'll need in your day to day work. No seriously, in what kind of environment have you used these tools and how long did it take you to figure out how to automate the installation of the usual third party tools you would need? – Voo Nov 24 '18 at 21:34
  • 1
    I'm asking because from experience, it's usually only the people who never had to figure out why MSSQL failed to install correctly automatically although it works perfectly fine if you try the same command line parameters in the interactive CLI session, who think this is trivial and done in an afternoon. Doable? Absolutely. But a pretty big investment that requires constant involvement (you need new images very regularly and the setup procedures change all the time). For a small company the ROI just doesn't exist in my experience. – Voo Nov 24 '18 at 21:35
1

There seems to be a mistaken assumption here, that a portable PC owned by an employer and an e-mail account provided and paid for by an employer in some sense belong to the employee. They don't! The situation is that you are employed and paid to operate their equipment and to process their data. (Ditto, the sysadmins).

So the only way to be certain of privacy, is to handle private matters on hardware that you own personally. Your mobile phone connected to the mobile network is probably that device, while you are at work. If you employer allows personal use of its connection to the internet at large, secure (https) communication with a personal account on an external e-mail service such as Gmail is almost as safe -- just as long as you trust your employer not to do anything blatantly immoral such as installing a keystroke-logger on your employer-owned PC to intercept your private password and a screen recorder to allow the employer to watch your screen later. In the EU this would be blatantly illegal unless the employers policies (which you have been made aware of and which are part of your contract of employment) warn of such. It's likely to be illegal even if they do, unless you are working in a particularly sensitive environment (in which case all personal use of the employer's hardware is likely to be forbidden for sensible security reasons).

The sysadmins are paid by the employer to maintain its assets in accordance with its policies. These policies ought to comply with the law. So in the EU there is an expectation of privacy with respect to e-mails, hedged around with actions necessary for the employer to perform. So a sysadmin may have to look at "private" e-mails in order to administer a mail server system, but should not ever reveal or act on what he sees unless it reveals some serious misconduct or crime. He certainly should never deliberately look at e-mails outside the policies set by the employer and known to the employee.

But a bad or corrupt sysadmin is privileged, so there is nothing you can do to protect yourself from him. If you don't fully trust your employer, at a minimum don't use it's hardware for private purposes that would hurt you were they to be made public. At a maximum, you should be looking for a new job!

In passing, I'm a small-company sysadmin, and set up PCs pretty much as described. At a previous employer, it was s.o.p. to send a single e-mail from the newly configured PC to the the sysadmin's company e-mail account, reply to that, and delete the reply, to make sure everything was working well. It was also s.o.p. to send a longer e-mail from the sysadmin to the newly created employee's account, generally welcoming him to the organisation and providing standard information about getting started. It would be waiting for them after they logged in for the first time, resetting their password.

nigel222
  • 219
  • 1
  • 4
1

I feel like this question just points out the dichotomy between "how we wish IT worked" vs. "how it really works".

At some time in history, I bet the IT guys setup a laptop for an exec. When they passed the laptop off, the exec was peeved when it didn't work or needed additional setup. So, they get yelled at, and that's probably when some policy started of "log in and make sure it's fully setup and working before hand-off".

Is this ideal? No. But, nobody in IT is ever surprised at the amount of accomodation IT makes to get things running smoothly in a company, especially when it impacts higher-ups.

It's sort of like how a contractor that gets hired, but keeps giving the hirer bad news will be out of business.. well, an IT dept that keeps running things by-the-book and upsetting the folks that hire them will eventually get replaced.

IT is often walking on eggshells, and has to pick-n-choose its battles.

Setting up a laptop and logging into it to do any post-setups for odd programs and double-check to make it all work (QA) before hand-off... that's something IT just made a concession for to make everyone's life easier. As long as IT admins were the only ones doing it, it was a "safe bet" to make.

But, when execs ask someone to log in for them and do work (to which, the admin could get suckered into cooking the books for someone without realizing it).. or an exec / manager asking IT to relax on a policy intended to protect users from themselves, or protect the servers from viruses (eg: "just let my people keep their passwords on post-its next to the computer"... um, no.)

You have to pick-n-choose your battles. You can nitpick policy all day long, and in fact if you keep digging into policy you'll be getting frustrated at seeing all the little consolations the IT dept is making to keep things running smoothly.

The other issue with this is that as the IT dept makes consolations, they can be seen as a group willing to bend rules.. so some folks may not take rules as seriously, or expect them to bend them to the point of breaking.

So, IT, much like Bruce Lee's Jeet Kun Do philosophy is "be like water". You want to fill the needs and desires of the company you're working for to make things go smoothly while also satisfying your primary purpose. But, you also want to be a force to be reckoned with if someone pushes you in a direction that is clearly bad for themselves or the company.

This is why there's a delicate balancing act at companies. You want to hire trustworty people in IT. I would rather have mediocre IT employees that I trust then rockstars I'm worried are finding ways to embezzle money on the side or pimping out the servers to work on contract work at night.

On the other hand, I also don't want exec staff to think they can walk all over IT. Dealing with IT should be like dealing with the police. They need to be trustworthy that they have enough power to push back against people being arrogant, but also trustworthy enough that they're not abusing their power.

So, tl;dr... I think you're getting stuck on a policy that doesn't look ideal from an academic / ideal perspective, but was probably born out of a past faux pas, and now acts as the IT dept caring enough to QA things before handing them off blindly.

blahblah
  • 11
  • 1
0

You buy a new car. At least once a year you take it to mechanic for maintenance (oil check etc.). Most of us will give mechanic a key and went to do something (shopping, coffee, etc.). They have a complete access to your car. They can do anything. Do you consider it as a big problem alto you could leave/forget your private/office laptop inside or some personal documents or....??

Just as maintenance of your car, preparing your account is something that need to be done. You can sit by, watching and pretending that you know what they are doing or let them do it by themselves trusting them they are professionals and know what they are doing.

In case of moving to a new job, I would be more concerned about my full mailbox left on old job that empty one on a new job.

Being paranoid is quite OK, as long as you are sure you know why you are paranoid.

This remind me of a GDPR joke:
In the doctors office nurse comes out saying: "Due to GDPR I'm not allowed to say your names in public, but the one with syphilis can go to see doctor...."

Kwisatz Haderach
  • 1
  • This does not answer the question and the analogy does not fit. The analogy would be "when buying a car, is it ok that the dealership had the keys first?" – schroeder Nov 22 '18 at 13:02
  • Wrong example! Having dealt too many times with non-professional mechanics I will now look with a different eye the IT guys! – Diego Pascotto Nov 22 '18 at 13:50