Krdytkyu

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.

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.

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.

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.

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.

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.

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.

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.

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...."

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.