Is it OK that a sysadmin knows the password for a newcomer / act as a user (immediately after his/her...











up vote
14
down vote

favorite
1












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










share|improve this question









New contributor




Diego Pascotto is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 5




    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.
    15 hours ago








  • 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
    15 hours ago






  • 3




    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
    15 hours ago






  • 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 Nathan
    15 hours ago






  • 1




    @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
    3 hours ago















up vote
14
down vote

favorite
1












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










share|improve this question









New contributor




Diego Pascotto is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
















  • 5




    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.
    15 hours ago








  • 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
    15 hours ago






  • 3




    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
    15 hours ago






  • 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 Nathan
    15 hours ago






  • 1




    @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
    3 hours ago













up vote
14
down vote

favorite
1









up vote
14
down vote

favorite
1






1





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










share|improve this question









New contributor




Diego Pascotto is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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







password-management password-policy






share|improve this question









New contributor




Diego Pascotto is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question









New contributor




Diego Pascotto is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question








edited 12 hours ago





















New contributor




Diego Pascotto is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked 16 hours ago









Diego Pascotto

7114




7114




New contributor




Diego Pascotto is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





Diego Pascotto is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






Diego Pascotto is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








  • 5




    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.
    15 hours ago








  • 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
    15 hours ago






  • 3




    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
    15 hours ago






  • 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 Nathan
    15 hours ago






  • 1




    @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
    3 hours ago














  • 5




    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.
    15 hours ago








  • 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
    15 hours ago






  • 3




    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
    15 hours ago






  • 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 Nathan
    15 hours ago






  • 1




    @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
    3 hours ago








5




5




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.
15 hours ago






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.
15 hours ago






1




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
15 hours ago




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
15 hours ago




3




3




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
15 hours ago




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
15 hours ago




1




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 Nathan
15 hours ago




@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 Nathan
15 hours ago




1




1




@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
3 hours ago




@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
3 hours ago










7 Answers
7






active

oldest

votes

















up vote
25
down vote














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 all configurations cannot 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.





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.






share|improve this answer



















  • 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 Nathan
    14 hours ago






  • 3




    Notice he said the email account is activated when setting up outlook. Any emails sent to the address before that point will bounce.
    – Joe
    12 hours ago






  • 7




    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
    11 hours ago






  • 3




    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
    8 hours ago






  • 4




    @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
    6 hours ago


















up vote
7
down vote













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.






share|improve this answer























  • "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
    5 hours ago








  • 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
    3 hours ago










  • 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
    2 hours ago


















up vote
5
down vote













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.






share|improve this answer

















  • 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
    15 hours ago






  • 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
    14 hours ago






  • 3




    @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
    13 hours ago






  • 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
    13 hours ago








  • 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
    11 hours ago


















up vote
3
down vote














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.






share|improve this answer




























    up vote
    2
    down vote













    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.






    share|improve this answer




























      up vote
      2
      down vote













      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.






      share|improve this answer




























        up vote
        0
        down vote













        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.






        share|improve this answer





















        • 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 Voorn
          1 hour ago










        • @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
          1 hour ago










        • @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
          1 hour ago












        • @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
          59 mins ago








        • 1




          @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
          49 mins ago











        Your Answer








        StackExchange.ready(function() {
        var channelOptions = {
        tags: "".split(" "),
        id: "162"
        };
        initTagRenderer("".split(" "), "".split(" "), channelOptions);

        StackExchange.using("externalEditor", function() {
        // Have to fire editor after snippets, if snippets enabled
        if (StackExchange.settings.snippets.snippetsEnabled) {
        StackExchange.using("snippets", function() {
        createEditor();
        });
        }
        else {
        createEditor();
        }
        });

        function createEditor() {
        StackExchange.prepareEditor({
        heartbeatType: 'answer',
        convertImagesToLinks: false,
        noModals: true,
        showLowRepImageUploadWarning: true,
        reputationToPostImages: null,
        bindNavPrevention: true,
        postfix: "",
        imageUploader: {
        brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
        contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
        allowUrls: true
        },
        noCode: true, onDemand: true,
        discardSelector: ".discard-answer"
        ,immediatelyShowMarkdownHelp:true
        });


        }
        });






        Diego Pascotto is a new contributor. Be nice, and check out our Code of Conduct.










         

        draft saved


        draft discarded


















        StackExchange.ready(
        function () {
        StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f198119%2fis-it-ok-that-a-sysadmin-knows-the-password-for-a-newcomer-act-as-a-user-imme%23new-answer', 'question_page');
        }
        );

        Post as a guest















        Required, but never shown

























        7 Answers
        7






        active

        oldest

        votes








        7 Answers
        7






        active

        oldest

        votes









        active

        oldest

        votes






        active

        oldest

        votes








        up vote
        25
        down vote














        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 all configurations cannot 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.





        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.






        share|improve this answer



















        • 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 Nathan
          14 hours ago






        • 3




          Notice he said the email account is activated when setting up outlook. Any emails sent to the address before that point will bounce.
          – Joe
          12 hours ago






        • 7




          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
          11 hours ago






        • 3




          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
          8 hours ago






        • 4




          @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
          6 hours ago















        up vote
        25
        down vote














        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 all configurations cannot 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.





        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.






        share|improve this answer



















        • 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 Nathan
          14 hours ago






        • 3




          Notice he said the email account is activated when setting up outlook. Any emails sent to the address before that point will bounce.
          – Joe
          12 hours ago






        • 7




          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
          11 hours ago






        • 3




          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
          8 hours ago






        • 4




          @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
          6 hours ago













        up vote
        25
        down vote










        up vote
        25
        down vote










        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 all configurations cannot 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.





        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.






        share|improve this answer















        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 all configurations cannot 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.





        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 14 hours ago

























        answered 15 hours ago









        Kolappan Nathan

        883514




        883514








        • 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 Nathan
          14 hours ago






        • 3




          Notice he said the email account is activated when setting up outlook. Any emails sent to the address before that point will bounce.
          – Joe
          12 hours ago






        • 7




          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
          11 hours ago






        • 3




          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
          8 hours ago






        • 4




          @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
          6 hours ago














        • 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 Nathan
          14 hours ago






        • 3




          Notice he said the email account is activated when setting up outlook. Any emails sent to the address before that point will bounce.
          – Joe
          12 hours ago






        • 7




          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
          11 hours ago






        • 3




          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
          8 hours ago






        • 4




          @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
          6 hours ago








        1




        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 Nathan
        14 hours ago




        @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 Nathan
        14 hours ago




        3




        3




        Notice he said the email account is activated when setting up outlook. Any emails sent to the address before that point will bounce.
        – Joe
        12 hours ago




        Notice he said the email account is activated when setting up outlook. Any emails sent to the address before that point will bounce.
        – Joe
        12 hours ago




        7




        7




        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
        11 hours ago




        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
        11 hours ago




        3




        3




        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
        8 hours ago




        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
        8 hours ago




        4




        4




        @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
        6 hours ago




        @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
        6 hours ago












        up vote
        7
        down vote













        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.






        share|improve this answer























        • "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
          5 hours ago








        • 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
          3 hours ago










        • 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
          2 hours ago















        up vote
        7
        down vote













        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.






        share|improve this answer























        • "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
          5 hours ago








        • 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
          3 hours ago










        • 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
          2 hours ago













        up vote
        7
        down vote










        up vote
        7
        down vote









        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.






        share|improve this answer














        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.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited 4 hours ago

























        answered 11 hours ago









        Lie Ryan

        20.6k24370




        20.6k24370












        • "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
          5 hours ago








        • 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
          3 hours ago










        • 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
          2 hours ago


















        • "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
          5 hours ago








        • 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
          3 hours ago










        • 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
          2 hours ago
















        "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
        5 hours ago






        "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
        5 hours ago






        2




        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
        3 hours ago




        @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
        3 hours ago












        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
        2 hours ago




        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
        2 hours ago










        up vote
        5
        down vote













        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.






        share|improve this answer

















        • 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
          15 hours ago






        • 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
          14 hours ago






        • 3




          @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
          13 hours ago






        • 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
          13 hours ago








        • 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
          11 hours ago















        up vote
        5
        down vote













        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.






        share|improve this answer

















        • 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
          15 hours ago






        • 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
          14 hours ago






        • 3




          @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
          13 hours ago






        • 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
          13 hours ago








        • 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
          11 hours ago













        up vote
        5
        down vote










        up vote
        5
        down vote









        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.






        share|improve this answer












        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered 15 hours ago









        Luc

        22.1k54096




        22.1k54096








        • 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
          15 hours ago






        • 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
          14 hours ago






        • 3




          @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
          13 hours ago






        • 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
          13 hours ago








        • 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
          11 hours ago














        • 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
          15 hours ago






        • 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
          14 hours ago






        • 3




          @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
          13 hours ago






        • 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
          13 hours ago








        • 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
          11 hours ago








        1




        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
        15 hours ago




        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
        15 hours ago




        5




        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
        14 hours ago




        @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
        14 hours ago




        3




        3




        @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
        13 hours ago




        @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
        13 hours ago




        5




        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
        13 hours ago






        @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
        13 hours ago






        1




        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
        11 hours ago




        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
        11 hours ago










        up vote
        3
        down vote














        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.






        share|improve this answer

























          up vote
          3
          down vote














          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.






          share|improve this answer























            up vote
            3
            down vote










            up vote
            3
            down vote










            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.






            share|improve this answer













            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.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered 8 hours ago









            Darkwing

            1824




            1824






















                up vote
                2
                down vote













                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.






                share|improve this answer

























                  up vote
                  2
                  down vote













                  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.






                  share|improve this answer























                    up vote
                    2
                    down vote










                    up vote
                    2
                    down vote









                    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.






                    share|improve this answer












                    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.







                    share|improve this answer












                    share|improve this answer



                    share|improve this answer










                    answered 10 hours ago









                    Tom K.

                    5,03632047




                    5,03632047






















                        up vote
                        2
                        down vote













                        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.






                        share|improve this answer

























                          up vote
                          2
                          down vote













                          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.






                          share|improve this answer























                            up vote
                            2
                            down vote










                            up vote
                            2
                            down vote









                            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.






                            share|improve this answer












                            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.







                            share|improve this answer












                            share|improve this answer



                            share|improve this answer










                            answered 7 hours ago









                            DoubleD

                            1,965119




                            1,965119






















                                up vote
                                0
                                down vote













                                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.






                                share|improve this answer





















                                • 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 Voorn
                                  1 hour ago










                                • @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
                                  1 hour ago










                                • @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
                                  1 hour ago












                                • @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
                                  59 mins ago








                                • 1




                                  @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
                                  49 mins ago















                                up vote
                                0
                                down vote













                                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.






                                share|improve this answer





















                                • 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 Voorn
                                  1 hour ago










                                • @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
                                  1 hour ago










                                • @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
                                  1 hour ago












                                • @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
                                  59 mins ago








                                • 1




                                  @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
                                  49 mins ago













                                up vote
                                0
                                down vote










                                up vote
                                0
                                down vote









                                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.






                                share|improve this answer












                                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.







                                share|improve this answer












                                share|improve this answer



                                share|improve this answer










                                answered 1 hour ago









                                barbecue

                                17115




                                17115












                                • 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 Voorn
                                  1 hour ago










                                • @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
                                  1 hour ago










                                • @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
                                  1 hour ago












                                • @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
                                  59 mins ago








                                • 1




                                  @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
                                  49 mins ago


















                                • 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 Voorn
                                  1 hour ago










                                • @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
                                  1 hour ago










                                • @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
                                  1 hour ago












                                • @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
                                  59 mins ago








                                • 1




                                  @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
                                  49 mins ago
















                                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 Voorn
                                1 hour ago




                                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 Voorn
                                1 hour ago












                                @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
                                1 hour ago




                                @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
                                1 hour ago












                                @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
                                1 hour ago






                                @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
                                1 hour ago














                                @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
                                59 mins ago






                                @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
                                59 mins ago






                                1




                                1




                                @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
                                49 mins ago




                                @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
                                49 mins ago










                                Diego Pascotto is a new contributor. Be nice, and check out our Code of Conduct.










                                 

                                draft saved


                                draft discarded


















                                Diego Pascotto is a new contributor. Be nice, and check out our Code of Conduct.













                                Diego Pascotto is a new contributor. Be nice, and check out our Code of Conduct.












                                Diego Pascotto is a new contributor. Be nice, and check out our Code of Conduct.















                                 


                                draft saved


                                draft discarded














                                StackExchange.ready(
                                function () {
                                StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f198119%2fis-it-ok-that-a-sysadmin-knows-the-password-for-a-newcomer-act-as-a-user-imme%23new-answer', 'question_page');
                                }
                                );

                                Post as a guest















                                Required, but never shown





















































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown

































                                Required, but never shown














                                Required, but never shown












                                Required, but never shown







                                Required, but never shown







                                Popular posts from this blog

                                A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks

                                Calculate evaluation metrics using cross_val_predict sklearn

                                Insert data from modal to MySQL (multiple modal on website)