Is it OK that a sysadmin knows the password for a newcomer / act as a user (immediately after his/her...
up vote
29
down vote
favorite
Somehow related to this other question. I am dealing with the following case: a medium-large company (with about 200 on-premises employees) is applying the following procedure for all the newly recruited employees (immediately before their first day at the company):
- they generate a password for the user (NOT a change-at-first-login
one) - they login on their laptop (impersonating the final user)
- they apply some configuration (e.g. they access their Outlook email in order to check that everything works)
- they change again the password (this time with a change-at-first-login one)
- the laptop is delivered to the user
It appears that this procedure is quite common also in IT companies.
I cannot say if the initial configuration, "in the name of user", is absolutely necessary or just dictated by convenience reasons (a fully working laptop is delivered to a non-IT user, preventing a lot of requests to the IT for fixing common issues), but there a few things that smell:
- if I should never tell an admin my password (as it has been answered
to the cited question) there is no reason that an admin knows my
password even at the very beginning of my work in that company - I can accept that an admin knows my password (when he first creates my account or when he resets it) provided that it's a
change-at-first-login password (so that I have evidence that it's not
been used before). I suspect anyway that most legacy systems (like
AD) allow admins to reset passwords with great freedom (for example
resetting passwords without notifying the user, or without forcing
them to set a change-at-first-login one). Is it an accepted practice?
This seems completely different from what happens for example in
Google (no one knows my password, if an activity is detected I am
notified).
Edit: to answer many comments that state that "the computer is not yours, it's the employer's computer, you should not have personal information on the company computer" I would like to point out that it's not a matter of personal information, but reserved information regarding the company business. So, if it's correct that I should not use my company email to receive my blood analysis results from my doctor, it's perfectly common that some reserved information about the company is exchanged between employee A and employee B.
password-management password-policy
New contributor
|
show 5 more comments
up vote
29
down vote
favorite
Somehow related to this other question. I am dealing with the following case: a medium-large company (with about 200 on-premises employees) is applying the following procedure for all the newly recruited employees (immediately before their first day at the company):
- they generate a password for the user (NOT a change-at-first-login
one) - they login on their laptop (impersonating the final user)
- they apply some configuration (e.g. they access their Outlook email in order to check that everything works)
- they change again the password (this time with a change-at-first-login one)
- the laptop is delivered to the user
It appears that this procedure is quite common also in IT companies.
I cannot say if the initial configuration, "in the name of user", is absolutely necessary or just dictated by convenience reasons (a fully working laptop is delivered to a non-IT user, preventing a lot of requests to the IT for fixing common issues), but there a few things that smell:
- if I should never tell an admin my password (as it has been answered
to the cited question) there is no reason that an admin knows my
password even at the very beginning of my work in that company - I can accept that an admin knows my password (when he first creates my account or when he resets it) provided that it's a
change-at-first-login password (so that I have evidence that it's not
been used before). I suspect anyway that most legacy systems (like
AD) allow admins to reset passwords with great freedom (for example
resetting passwords without notifying the user, or without forcing
them to set a change-at-first-login one). Is it an accepted practice?
This seems completely different from what happens for example in
Google (no one knows my password, if an activity is detected I am
notified).
Edit: to answer many comments that state that "the computer is not yours, it's the employer's computer, you should not have personal information on the company computer" I would like to point out that it's not a matter of personal information, but reserved information regarding the company business. So, if it's correct that I should not use my company email to receive my blood analysis results from my doctor, it's perfectly common that some reserved information about the company is exchanged between employee A and employee B.
password-management password-policy
New contributor
14
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.
yesterday
5
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
yesterday
7
@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
yesterday
4
For those that argue about automation - you probably live in a dream-world. At least since Laptop-Vendors startet to use different hardware depending on pricing for the same laptop series, there is no guarantee an image will run on another laptop with the same config. Andere there are a myriad more pitfalls, where a certain username, windows update, combination of roles, ... could lead to new problems on the "same" hardware with the "same" automatic config.
– Falco
17 hours ago
2
@wizzwizz4: I'm not so silly as to disable the logs by running the command to disable logs. It's more like "started mmc.exe with elevated token".
– Joshua
12 hours ago
|
show 5 more comments
up vote
29
down vote
favorite
up vote
29
down vote
favorite
Somehow related to this other question. I am dealing with the following case: a medium-large company (with about 200 on-premises employees) is applying the following procedure for all the newly recruited employees (immediately before their first day at the company):
- they generate a password for the user (NOT a change-at-first-login
one) - they login on their laptop (impersonating the final user)
- they apply some configuration (e.g. they access their Outlook email in order to check that everything works)
- they change again the password (this time with a change-at-first-login one)
- the laptop is delivered to the user
It appears that this procedure is quite common also in IT companies.
I cannot say if the initial configuration, "in the name of user", is absolutely necessary or just dictated by convenience reasons (a fully working laptop is delivered to a non-IT user, preventing a lot of requests to the IT for fixing common issues), but there a few things that smell:
- if I should never tell an admin my password (as it has been answered
to the cited question) there is no reason that an admin knows my
password even at the very beginning of my work in that company - I can accept that an admin knows my password (when he first creates my account or when he resets it) provided that it's a
change-at-first-login password (so that I have evidence that it's not
been used before). I suspect anyway that most legacy systems (like
AD) allow admins to reset passwords with great freedom (for example
resetting passwords without notifying the user, or without forcing
them to set a change-at-first-login one). Is it an accepted practice?
This seems completely different from what happens for example in
Google (no one knows my password, if an activity is detected I am
notified).
Edit: to answer many comments that state that "the computer is not yours, it's the employer's computer, you should not have personal information on the company computer" I would like to point out that it's not a matter of personal information, but reserved information regarding the company business. So, if it's correct that I should not use my company email to receive my blood analysis results from my doctor, it's perfectly common that some reserved information about the company is exchanged between employee A and employee B.
password-management password-policy
New contributor
Somehow related to this other question. I am dealing with the following case: a medium-large company (with about 200 on-premises employees) is applying the following procedure for all the newly recruited employees (immediately before their first day at the company):
- they generate a password for the user (NOT a change-at-first-login
one) - they login on their laptop (impersonating the final user)
- they apply some configuration (e.g. they access their Outlook email in order to check that everything works)
- they change again the password (this time with a change-at-first-login one)
- the laptop is delivered to the user
It appears that this procedure is quite common also in IT companies.
I cannot say if the initial configuration, "in the name of user", is absolutely necessary or just dictated by convenience reasons (a fully working laptop is delivered to a non-IT user, preventing a lot of requests to the IT for fixing common issues), but there a few things that smell:
- if I should never tell an admin my password (as it has been answered
to the cited question) there is no reason that an admin knows my
password even at the very beginning of my work in that company - I can accept that an admin knows my password (when he first creates my account or when he resets it) provided that it's a
change-at-first-login password (so that I have evidence that it's not
been used before). I suspect anyway that most legacy systems (like
AD) allow admins to reset passwords with great freedom (for example
resetting passwords without notifying the user, or without forcing
them to set a change-at-first-login one). Is it an accepted practice?
This seems completely different from what happens for example in
Google (no one knows my password, if an activity is detected I am
notified).
Edit: to answer many comments that state that "the computer is not yours, it's the employer's computer, you should not have personal information on the company computer" I would like to point out that it's not a matter of personal information, but reserved information regarding the company business. So, if it's correct that I should not use my company email to receive my blood analysis results from my doctor, it's perfectly common that some reserved information about the company is exchanged between employee A and employee B.
password-management password-policy
password-management password-policy
New contributor
New contributor
edited 14 hours ago
New contributor
asked yesterday
Diego Pascotto
14624
14624
New contributor
New contributor
14
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.
yesterday
5
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
yesterday
7
@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
yesterday
4
For those that argue about automation - you probably live in a dream-world. At least since Laptop-Vendors startet to use different hardware depending on pricing for the same laptop series, there is no guarantee an image will run on another laptop with the same config. Andere there are a myriad more pitfalls, where a certain username, windows update, combination of roles, ... could lead to new problems on the "same" hardware with the "same" automatic config.
– Falco
17 hours ago
2
@wizzwizz4: I'm not so silly as to disable the logs by running the command to disable logs. It's more like "started mmc.exe with elevated token".
– Joshua
12 hours ago
|
show 5 more comments
14
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.
yesterday
5
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
yesterday
7
@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
yesterday
4
For those that argue about automation - you probably live in a dream-world. At least since Laptop-Vendors startet to use different hardware depending on pricing for the same laptop series, there is no guarantee an image will run on another laptop with the same config. Andere there are a myriad more pitfalls, where a certain username, windows update, combination of roles, ... could lead to new problems on the "same" hardware with the "same" automatic config.
– Falco
17 hours ago
2
@wizzwizz4: I'm not so silly as to disable the logs by running the command to disable logs. It's more like "started mmc.exe with elevated token".
– Joshua
12 hours ago
14
14
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.
yesterday
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.
yesterday
5
5
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
yesterday
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
yesterday
7
7
@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
yesterday
@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
yesterday
4
4
For those that argue about automation - you probably live in a dream-world. At least since Laptop-Vendors startet to use different hardware depending on pricing for the same laptop series, there is no guarantee an image will run on another laptop with the same config. Andere there are a myriad more pitfalls, where a certain username, windows update, combination of roles, ... could lead to new problems on the "same" hardware with the "same" automatic config.
– Falco
17 hours ago
For those that argue about automation - you probably live in a dream-world. At least since Laptop-Vendors startet to use different hardware depending on pricing for the same laptop series, there is no guarantee an image will run on another laptop with the same config. Andere there are a myriad more pitfalls, where a certain username, windows update, combination of roles, ... could lead to new problems on the "same" hardware with the "same" automatic config.
– Falco
17 hours ago
2
2
@wizzwizz4: I'm not so silly as to disable the logs by running the command to disable logs. It's more like "started mmc.exe with elevated token".
– Joshua
12 hours ago
@wizzwizz4: I'm not so silly as to disable the logs by running the command to disable logs. It's more like "started mmc.exe with elevated token".
– Joshua
12 hours ago
|
show 5 more comments
9 Answers
9
active
oldest
votes
up vote
55
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 not all configurations can be changed at Admin level. Some things can only be performed by the user. Instead of telling each and every user to perform a set of steps, they are doing it ahead of time.
Some other concerns of sharing a password do not apply here such as
- Reusing the password is irrelevant as the password is not yours.
- None of your personal information is associated with the password.
To answer some comments,
I suspect that "there is no data associated with the account at the
very beginning" it's not absolutely true: I could have some emails in
my mailbox (someone could have sent my some confidential info to my
email address, because the mailbox has been activated before I first
log in)
by Diego Pascotto
Mail Id should not be shared to anyone by the Admins before configuration. The mailbox must have been activated when setting up outlook. Email Ids are shared only after single sign-in password is set. Also as pointed out by James Snell, receiving an email within minutes of account creation is unlikely.
A competent company has images, procedures, via automation that take
care of these things without ever logging in as the new user at any
time.
by Sokel
Small companies do not always invest in automating. If a company hires around 10 staff per year and each with a different role the effort required to bring automation and maintain it will be greater than the manual effort. Automation is only worth the effort when you are having job that is done repeatedly in large numbers.
If the admin has had unmonitored access to your account at any point
in time; they could've set up anything under your name - preventing
any returns to them.
by UKMonkey
Any actions taken by the admins during this time can be linked back to them as it is clear that the account is not handed over to the user until the user resets the password using the sign sign-on password.
3
What do you mean by 'not share your email id'? If the company policy for assigning email address is name.surname@mycompany.com anyone can guess my email and send me a message before I actually log in .
– Diego Pascotto
yesterday
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
yesterday
14
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
yesterday
5
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
yesterday
10
@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
yesterday
|
show 14 more comments
up vote
16
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.
"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
yesterday
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
yesterday
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
yesterday
add a comment |
up vote
7
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.
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
yesterday
@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
yesterday
2
@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
yesterday
1
@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
yesterday
2
@KevinVoorn If you can be more specific about exactly what you see as a flaw in my reasoning I'll try to address it. I'm specifically addressing the question of whether or not there is an inherent security risk in logging in under other users' credentials before they take possession of the account, and I can't see any that don't also exist if a different procedure is followed.
– barbecue
yesterday
|
show 3 more comments
up vote
6
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.
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
yesterday
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
yesterday
4
@DiegoPascotto In the answer I said "there are a thousand other (easier) ways to do malicious things". One example of that is reading/sending email on behalf of the user: the admin can already do that without logging in as the user. Either the admin logs in with their admin account and reads your mail file (e.g. PST file), or they look in your mailbox on the server side. Sending can be done using telnet. For malicious actions, there is no advantage to changing the user's password temporarily and then logging in as the user.
– Luc
yesterday
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
yesterday
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
yesterday
|
show 1 more comment
up vote
5
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.
add a comment |
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.
add a comment |
up vote
1
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.
Edit:
As this answer has stirred up some conversation, let me add the following:
Here are the some tools to provision Windows images to company hardware, for Windows 8 the Microsoft Deployment Toolkit and the System Center Configuration Manager for Windows 10. These tools are official Microsoft tools, they are free (as far as I can tell) and from frist glance pretty well documented. There you can implement and document all processes for provisioning Windows 8/10 on company hardware easily. All admin accesses to a machine should be done via tools like these and should be logged with a logging server. Then there are less possibilities for a single admin to manipulate a single machine.
If an admin handles every machine by hand, 1) manipulation is possible and 2) errors are bound to happen. An automated process can be reviewed and audited, a manual process is impossible to control.
The commitment to tools like these is a step towards a more secure provisioning of operating systems and user accounts in a company environment.
How can the procedure such as setting up Outlook app on a person's laptop be automated? Also small companies do not always invest in automating. If a company hires around 10 staff per year the effort required to bring automation and maintain it will be greater than the manual effort.
– Kolappan Nathan
yesterday
1
To automate a 10 minute system config process will take far more than 10 minutes, and will definitely require a much more expensive System Admin. If you get an incompetent Admin to do the automation, best-case scenario is it'll not work. Worst-case scenario is they open up every system to vulnerabilities. You also need a manager that can tell the difference and knows how to hire for automation. It is a much more expensive endeavor. Ever tried making a custom Windows install disc with specific pre-installed drivers? It took me several hours the first time...
– Nelson
23 hours ago
@Nelson I'm not sure where you are getting at? According to this scientific chart(!), saving 30 minutes weekly (which I'm pretty sure that this task will take if I read OP right) one can invest 21 hours into this.
– Tom K.
21 hours ago
@KolappanNathan I don't know. I'm not a Windows Sysadmin, but I'm sure there's a way.
– Tom K.
21 hours ago
I can assure you 21 hours of automation will last maybe 1 month, then you'll have to do it again when new things come out. It's a lot more complicated if the company is not running a dumb terminal. Different departments, different software packages, etc. It is a massive amount of time, and it changes, at minimum, yearly, across every department.
– Nelson
20 hours ago
|
show 6 more comments
up vote
0
down vote
There seems to be a mistaken assumption here, that a portable PC owned by an employer and an e-mail account provided and paid for by an employer in some sense belong to the employee. They don't! The situation is that you are employed and paid to operate their equipment and to process their data. (Ditto, the sysadmins).
So the only way to be certain of privacy, is to handle private matters on hardware that you own personally. Your mobile phone connected to the mobile network is probably that device, while you are at work. If you employer allows personal use of its connection to the internet at large, secure (https) communication with a personal account on an external e-mail service such as Gmail is almost as safe -- just as long as you trust your employer not to do anything blatantly immoral such as installing a keystroke-logger on your employer-owned PC to intercept your private password and a screen recorder to allow the employer to watch your screen later. In the EU this would be blatantly illegal unless the employers policies (which you have been made aware of and which are part of your contract of employment) warn of such. It's likely to be illegal even if they do, unless you are working in a particularly sensitive environment (in which case all personal use of the employer's hardware is likely to be forbidden for sensible security reasons).
The sysadmins are paid by the employer to maintain its assets in accordance with its policies. These policies ought to comply with the law. So in the EU there is an expectation of privacy with respect to e-mails, hedged around with actions necessary for the employer to perform. So a sysadmin may have to look at "private" e-mails in order to administer a mail server system, but should not ever reveal or act on what he sees unless it reveals some serious misconduct or crime. He certainly should never deliberately look at e-mails outside the policies set by the employer and known to the employee.
But a bad or corrupt sysadmin is privileged, so there is nothing you can do to protect yourself from him. If you don't fully trust your employer, at a minimum don't use it's hardware for private purposes that would hurt you were they to be made public. At a maximum, you should be looking for a new job!
In passing, I'm a small-company sysadmin, and set up PCs pretty much as described. At a previous employer, it was s.o.p. to send a single e-mail from the newly configured PC to the the sysadmin's company e-mail account, reply to that, and delete the reply, to make sure everything was working well. It was also s.o.p. to send a longer e-mail from the sysadmin to the newly created employee's account, generally welcoming him to the organisation and providing standard information about getting started. It would be waiting for them after they logged in for the first time, resetting their password.
add a comment |
up vote
0
down vote
You buy a new car. At least once a year you take it to mechanic for maintenance (oil check etc.). Most of us will give mechanic a key and went to do something (shopping, coffee, etc.). They have a complete access to your car. They can do anything. Do you consider it as a big problem alto you could leave/forget your private/office laptop inside or some personal documents or....??
Just as maintenance of your car, preparing your account is something that need to be done. You can sit by, watching and pretending that you know what they are doing or let them do it by themselves trusting them they are professionals and know what they are doing.
In case of moving to a new job, I would be more concerned about my full mailbox left on old job that empty one on a new job.
Being paranoid is quite OK, as long as you are sure you know why you are paranoid.
This remind me of a GDPR joke:
In the doctors office nurse comes out saying: "Due to GDPR I'm not allowed to say your names in public, but the one with syphilis can go to see doctor...."
New contributor
This does not answer the question and the analogy does not fit. The analogy would be "when buying a car, is it ok that the dealership had the keys first?"
– schroeder♦
15 hours ago
Wrong example! Having dealt too many times with non-professional mechanics I will now look with a different eye the IT guys!
– Diego Pascotto
14 hours ago
add a comment |
9 Answers
9
active
oldest
votes
9 Answers
9
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
55
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 not all configurations can be changed at Admin level. Some things can only be performed by the user. Instead of telling each and every user to perform a set of steps, they are doing it ahead of time.
Some other concerns of sharing a password do not apply here such as
- Reusing the password is irrelevant as the password is not yours.
- None of your personal information is associated with the password.
To answer some comments,
I suspect that "there is no data associated with the account at the
very beginning" it's not absolutely true: I could have some emails in
my mailbox (someone could have sent my some confidential info to my
email address, because the mailbox has been activated before I first
log in)
by Diego Pascotto
Mail Id should not be shared to anyone by the Admins before configuration. The mailbox must have been activated when setting up outlook. Email Ids are shared only after single sign-in password is set. Also as pointed out by James Snell, receiving an email within minutes of account creation is unlikely.
A competent company has images, procedures, via automation that take
care of these things without ever logging in as the new user at any
time.
by Sokel
Small companies do not always invest in automating. If a company hires around 10 staff per year and each with a different role the effort required to bring automation and maintain it will be greater than the manual effort. Automation is only worth the effort when you are having job that is done repeatedly in large numbers.
If the admin has had unmonitored access to your account at any point
in time; they could've set up anything under your name - preventing
any returns to them.
by UKMonkey
Any actions taken by the admins during this time can be linked back to them as it is clear that the account is not handed over to the user until the user resets the password using the sign sign-on password.
3
What do you mean by 'not share your email id'? If the company policy for assigning email address is name.surname@mycompany.com anyone can guess my email and send me a message before I actually log in .
– Diego Pascotto
yesterday
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
yesterday
14
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
yesterday
5
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
yesterday
10
@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
yesterday
|
show 14 more comments
up vote
55
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 not all configurations can be changed at Admin level. Some things can only be performed by the user. Instead of telling each and every user to perform a set of steps, they are doing it ahead of time.
Some other concerns of sharing a password do not apply here such as
- Reusing the password is irrelevant as the password is not yours.
- None of your personal information is associated with the password.
To answer some comments,
I suspect that "there is no data associated with the account at the
very beginning" it's not absolutely true: I could have some emails in
my mailbox (someone could have sent my some confidential info to my
email address, because the mailbox has been activated before I first
log in)
by Diego Pascotto
Mail Id should not be shared to anyone by the Admins before configuration. The mailbox must have been activated when setting up outlook. Email Ids are shared only after single sign-in password is set. Also as pointed out by James Snell, receiving an email within minutes of account creation is unlikely.
A competent company has images, procedures, via automation that take
care of these things without ever logging in as the new user at any
time.
by Sokel
Small companies do not always invest in automating. If a company hires around 10 staff per year and each with a different role the effort required to bring automation and maintain it will be greater than the manual effort. Automation is only worth the effort when you are having job that is done repeatedly in large numbers.
If the admin has had unmonitored access to your account at any point
in time; they could've set up anything under your name - preventing
any returns to them.
by UKMonkey
Any actions taken by the admins during this time can be linked back to them as it is clear that the account is not handed over to the user until the user resets the password using the sign sign-on password.
3
What do you mean by 'not share your email id'? If the company policy for assigning email address is name.surname@mycompany.com anyone can guess my email and send me a message before I actually log in .
– Diego Pascotto
yesterday
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
yesterday
14
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
yesterday
5
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
yesterday
10
@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
yesterday
|
show 14 more comments
up vote
55
down vote
up vote
55
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 not all configurations can be changed at Admin level. Some things can only be performed by the user. Instead of telling each and every user to perform a set of steps, they are doing it ahead of time.
Some other concerns of sharing a password do not apply here such as
- Reusing the password is irrelevant as the password is not yours.
- None of your personal information is associated with the password.
To answer some comments,
I suspect that "there is no data associated with the account at the
very beginning" it's not absolutely true: I could have some emails in
my mailbox (someone could have sent my some confidential info to my
email address, because the mailbox has been activated before I first
log in)
by Diego Pascotto
Mail Id should not be shared to anyone by the Admins before configuration. The mailbox must have been activated when setting up outlook. Email Ids are shared only after single sign-in password is set. Also as pointed out by James Snell, receiving an email within minutes of account creation is unlikely.
A competent company has images, procedures, via automation that take
care of these things without ever logging in as the new user at any
time.
by Sokel
Small companies do not always invest in automating. If a company hires around 10 staff per year and each with a different role the effort required to bring automation and maintain it will be greater than the manual effort. Automation is only worth the effort when you are having job that is done repeatedly in large numbers.
If the admin has had unmonitored access to your account at any point
in time; they could've set up anything under your name - preventing
any returns to them.
by UKMonkey
Any actions taken by the admins during this time can be linked back to them as it is clear that the account is not handed over to the user until the user resets the password using the sign sign-on password.
If I should never tell an admin my password (as it has been answered
to the cited question) there is no reason that an admin knows my
password even at the very beginning of my work in that company
One of the main reasons to this rule is that Admins should not access your confidential data such as mails, etc... Since there is no data associated with the account at the very beginning this is not an issue.
they generate a password for the user (NOT a change-at-first-login one)
Using a single sign-on password will ask for a normal password before one can change the configuration. So a password is needed before accessing the config.
I suspect anyway that most legacy systems allow admins to reset
passwords with great freedom. Is it an accepted practice?
This is an accepted practice. Not old systems but newer systems like Office 365 also allows the admins to reset the users password without notifying the user. However any such resets gets logged in the system and the admin will be held responsible for any issues.
Also note that not all configurations can be changed at Admin level. Some things can only be performed by the user. Instead of telling each and every user to perform a set of steps, they are doing it ahead of time.
Some other concerns of sharing a password do not apply here such as
- Reusing the password is irrelevant as the password is not yours.
- None of your personal information is associated with the password.
To answer some comments,
I suspect that "there is no data associated with the account at the
very beginning" it's not absolutely true: I could have some emails in
my mailbox (someone could have sent my some confidential info to my
email address, because the mailbox has been activated before I first
log in)
by Diego Pascotto
Mail Id should not be shared to anyone by the Admins before configuration. The mailbox must have been activated when setting up outlook. Email Ids are shared only after single sign-in password is set. Also as pointed out by James Snell, receiving an email within minutes of account creation is unlikely.
A competent company has images, procedures, via automation that take
care of these things without ever logging in as the new user at any
time.
by Sokel
Small companies do not always invest in automating. If a company hires around 10 staff per year and each with a different role the effort required to bring automation and maintain it will be greater than the manual effort. Automation is only worth the effort when you are having job that is done repeatedly in large numbers.
If the admin has had unmonitored access to your account at any point
in time; they could've set up anything under your name - preventing
any returns to them.
by UKMonkey
Any actions taken by the admins during this time can be linked back to them as it is clear that the account is not handed over to the user until the user resets the password using the sign sign-on password.
edited 11 hours ago
Will Da Silva
1033
1033
answered yesterday
Kolappan Nathan
1,063515
1,063515
3
What do you mean by 'not share your email id'? If the company policy for assigning email address is name.surname@mycompany.com anyone can guess my email and send me a message before I actually log in .
– Diego Pascotto
yesterday
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
yesterday
14
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
yesterday
5
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
yesterday
10
@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
yesterday
|
show 14 more comments
3
What do you mean by 'not share your email id'? If the company policy for assigning email address is name.surname@mycompany.com anyone can guess my email and send me a message before I actually log in .
– Diego Pascotto
yesterday
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
yesterday
14
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
yesterday
5
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
yesterday
10
@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
yesterday
3
3
What do you mean by 'not share your email id'? If the company policy for assigning email address is name.surname@mycompany.com anyone can guess my email and send me a message before I actually log in .
– Diego Pascotto
yesterday
What do you mean by 'not share your email id'? If the company policy for assigning email address is name.surname@mycompany.com anyone can guess my email and send me a message before I actually log in .
– Diego Pascotto
yesterday
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
yesterday
Notice he said the email account is activated when setting up outlook. Any emails sent to the address before that point will bounce.
– Joe
yesterday
14
14
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
yesterday
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
yesterday
5
5
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
yesterday
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
yesterday
10
10
@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
yesterday
@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
yesterday
|
show 14 more comments
up vote
16
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.
"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
yesterday
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
yesterday
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
yesterday
add a comment |
up vote
16
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.
"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
yesterday
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
yesterday
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
yesterday
add a comment |
up vote
16
down vote
up vote
16
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.
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.
edited yesterday
answered yesterday
Lie Ryan
20.7k24371
20.7k24371
"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
yesterday
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
yesterday
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
yesterday
add a comment |
"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
yesterday
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
yesterday
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
yesterday
"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
yesterday
"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
yesterday
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
yesterday
@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
yesterday
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
yesterday
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
yesterday
add a comment |
up vote
7
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.
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
yesterday
@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
yesterday
2
@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
yesterday
1
@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
yesterday
2
@KevinVoorn If you can be more specific about exactly what you see as a flaw in my reasoning I'll try to address it. I'm specifically addressing the question of whether or not there is an inherent security risk in logging in under other users' credentials before they take possession of the account, and I can't see any that don't also exist if a different procedure is followed.
– barbecue
yesterday
|
show 3 more comments
up vote
7
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.
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
yesterday
@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
yesterday
2
@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
yesterday
1
@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
yesterday
2
@KevinVoorn If you can be more specific about exactly what you see as a flaw in my reasoning I'll try to address it. I'm specifically addressing the question of whether or not there is an inherent security risk in logging in under other users' credentials before they take possession of the account, and I can't see any that don't also exist if a different procedure is followed.
– barbecue
yesterday
|
show 3 more comments
up vote
7
down vote
up vote
7
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.
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.
answered yesterday
barbecue
24125
24125
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
yesterday
@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
yesterday
2
@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
yesterday
1
@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
yesterday
2
@KevinVoorn If you can be more specific about exactly what you see as a flaw in my reasoning I'll try to address it. I'm specifically addressing the question of whether or not there is an inherent security risk in logging in under other users' credentials before they take possession of the account, and I can't see any that don't also exist if a different procedure is followed.
– barbecue
yesterday
|
show 3 more comments
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
yesterday
@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
yesterday
2
@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
yesterday
1
@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
yesterday
2
@KevinVoorn If you can be more specific about exactly what you see as a flaw in my reasoning I'll try to address it. I'm specifically addressing the question of whether or not there is an inherent security risk in logging in under other users' credentials before they take possession of the account, and I can't see any that don't also exist if a different procedure is followed.
– barbecue
yesterday
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
yesterday
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
yesterday
@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
yesterday
@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
yesterday
2
2
@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
yesterday
@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
yesterday
1
1
@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
yesterday
@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
yesterday
2
2
@KevinVoorn If you can be more specific about exactly what you see as a flaw in my reasoning I'll try to address it. I'm specifically addressing the question of whether or not there is an inherent security risk in logging in under other users' credentials before they take possession of the account, and I can't see any that don't also exist if a different procedure is followed.
– barbecue
yesterday
@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
yesterday
|
show 3 more comments
up vote
6
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.
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
yesterday
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
yesterday
4
@DiegoPascotto In the answer I said "there are a thousand other (easier) ways to do malicious things". One example of that is reading/sending email on behalf of the user: the admin can already do that without logging in as the user. Either the admin logs in with their admin account and reads your mail file (e.g. PST file), or they look in your mailbox on the server side. Sending can be done using telnet. For malicious actions, there is no advantage to changing the user's password temporarily and then logging in as the user.
– Luc
yesterday
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
yesterday
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
yesterday
|
show 1 more comment
up vote
6
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.
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
yesterday
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
yesterday
4
@DiegoPascotto In the answer I said "there are a thousand other (easier) ways to do malicious things". One example of that is reading/sending email on behalf of the user: the admin can already do that without logging in as the user. Either the admin logs in with their admin account and reads your mail file (e.g. PST file), or they look in your mailbox on the server side. Sending can be done using telnet. For malicious actions, there is no advantage to changing the user's password temporarily and then logging in as the user.
– Luc
yesterday
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
yesterday
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
yesterday
|
show 1 more comment
up vote
6
down vote
up vote
6
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.
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.
answered yesterday
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
yesterday
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
yesterday
4
@DiegoPascotto In the answer I said "there are a thousand other (easier) ways to do malicious things". One example of that is reading/sending email on behalf of the user: the admin can already do that without logging in as the user. Either the admin logs in with their admin account and reads your mail file (e.g. PST file), or they look in your mailbox on the server side. Sending can be done using telnet. For malicious actions, there is no advantage to changing the user's password temporarily and then logging in as the user.
– Luc
yesterday
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
yesterday
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
yesterday
|
show 1 more comment
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
yesterday
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
yesterday
4
@DiegoPascotto In the answer I said "there are a thousand other (easier) ways to do malicious things". One example of that is reading/sending email on behalf of the user: the admin can already do that without logging in as the user. Either the admin logs in with their admin account and reads your mail file (e.g. PST file), or they look in your mailbox on the server side. Sending can be done using telnet. For malicious actions, there is no advantage to changing the user's password temporarily and then logging in as the user.
– Luc
yesterday
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
yesterday
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
yesterday
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
yesterday
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
yesterday
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
yesterday
@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
yesterday
4
4
@DiegoPascotto In the answer I said "there are a thousand other (easier) ways to do malicious things". One example of that is reading/sending email on behalf of the user: the admin can already do that without logging in as the user. Either the admin logs in with their admin account and reads your mail file (e.g. PST file), or they look in your mailbox on the server side. Sending can be done using telnet. For malicious actions, there is no advantage to changing the user's password temporarily and then logging in as the user.
– Luc
yesterday
@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
yesterday
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
yesterday
@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
yesterday
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
yesterday
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
yesterday
|
show 1 more comment
up vote
5
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.
add a comment |
up vote
5
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.
add a comment |
up vote
5
down vote
up vote
5
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.
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.
answered yesterday
Darkwing
20114
20114
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered yesterday
DoubleD
1,965119
1,965119
add a comment |
add a comment |
up vote
1
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.
Edit:
As this answer has stirred up some conversation, let me add the following:
Here are the some tools to provision Windows images to company hardware, for Windows 8 the Microsoft Deployment Toolkit and the System Center Configuration Manager for Windows 10. These tools are official Microsoft tools, they are free (as far as I can tell) and from frist glance pretty well documented. There you can implement and document all processes for provisioning Windows 8/10 on company hardware easily. All admin accesses to a machine should be done via tools like these and should be logged with a logging server. Then there are less possibilities for a single admin to manipulate a single machine.
If an admin handles every machine by hand, 1) manipulation is possible and 2) errors are bound to happen. An automated process can be reviewed and audited, a manual process is impossible to control.
The commitment to tools like these is a step towards a more secure provisioning of operating systems and user accounts in a company environment.
How can the procedure such as setting up Outlook app on a person's laptop be automated? Also small companies do not always invest in automating. If a company hires around 10 staff per year the effort required to bring automation and maintain it will be greater than the manual effort.
– Kolappan Nathan
yesterday
1
To automate a 10 minute system config process will take far more than 10 minutes, and will definitely require a much more expensive System Admin. If you get an incompetent Admin to do the automation, best-case scenario is it'll not work. Worst-case scenario is they open up every system to vulnerabilities. You also need a manager that can tell the difference and knows how to hire for automation. It is a much more expensive endeavor. Ever tried making a custom Windows install disc with specific pre-installed drivers? It took me several hours the first time...
– Nelson
23 hours ago
@Nelson I'm not sure where you are getting at? According to this scientific chart(!), saving 30 minutes weekly (which I'm pretty sure that this task will take if I read OP right) one can invest 21 hours into this.
– Tom K.
21 hours ago
@KolappanNathan I don't know. I'm not a Windows Sysadmin, but I'm sure there's a way.
– Tom K.
21 hours ago
I can assure you 21 hours of automation will last maybe 1 month, then you'll have to do it again when new things come out. It's a lot more complicated if the company is not running a dumb terminal. Different departments, different software packages, etc. It is a massive amount of time, and it changes, at minimum, yearly, across every department.
– Nelson
20 hours ago
|
show 6 more comments
up vote
1
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.
Edit:
As this answer has stirred up some conversation, let me add the following:
Here are the some tools to provision Windows images to company hardware, for Windows 8 the Microsoft Deployment Toolkit and the System Center Configuration Manager for Windows 10. These tools are official Microsoft tools, they are free (as far as I can tell) and from frist glance pretty well documented. There you can implement and document all processes for provisioning Windows 8/10 on company hardware easily. All admin accesses to a machine should be done via tools like these and should be logged with a logging server. Then there are less possibilities for a single admin to manipulate a single machine.
If an admin handles every machine by hand, 1) manipulation is possible and 2) errors are bound to happen. An automated process can be reviewed and audited, a manual process is impossible to control.
The commitment to tools like these is a step towards a more secure provisioning of operating systems and user accounts in a company environment.
How can the procedure such as setting up Outlook app on a person's laptop be automated? Also small companies do not always invest in automating. If a company hires around 10 staff per year the effort required to bring automation and maintain it will be greater than the manual effort.
– Kolappan Nathan
yesterday
1
To automate a 10 minute system config process will take far more than 10 minutes, and will definitely require a much more expensive System Admin. If you get an incompetent Admin to do the automation, best-case scenario is it'll not work. Worst-case scenario is they open up every system to vulnerabilities. You also need a manager that can tell the difference and knows how to hire for automation. It is a much more expensive endeavor. Ever tried making a custom Windows install disc with specific pre-installed drivers? It took me several hours the first time...
– Nelson
23 hours ago
@Nelson I'm not sure where you are getting at? According to this scientific chart(!), saving 30 minutes weekly (which I'm pretty sure that this task will take if I read OP right) one can invest 21 hours into this.
– Tom K.
21 hours ago
@KolappanNathan I don't know. I'm not a Windows Sysadmin, but I'm sure there's a way.
– Tom K.
21 hours ago
I can assure you 21 hours of automation will last maybe 1 month, then you'll have to do it again when new things come out. It's a lot more complicated if the company is not running a dumb terminal. Different departments, different software packages, etc. It is a massive amount of time, and it changes, at minimum, yearly, across every department.
– Nelson
20 hours ago
|
show 6 more comments
up vote
1
down vote
up vote
1
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.
Edit:
As this answer has stirred up some conversation, let me add the following:
Here are the some tools to provision Windows images to company hardware, for Windows 8 the Microsoft Deployment Toolkit and the System Center Configuration Manager for Windows 10. These tools are official Microsoft tools, they are free (as far as I can tell) and from frist glance pretty well documented. There you can implement and document all processes for provisioning Windows 8/10 on company hardware easily. All admin accesses to a machine should be done via tools like these and should be logged with a logging server. Then there are less possibilities for a single admin to manipulate a single machine.
If an admin handles every machine by hand, 1) manipulation is possible and 2) errors are bound to happen. An automated process can be reviewed and audited, a manual process is impossible to control.
The commitment to tools like these is a step towards a more secure provisioning of operating systems and user accounts in a company environment.
What the other answers miss IMO is:
Why isn't this process automated?
Provisioning of user accounts (no matter of the operating system) is nothing what an admin should do by hand over and over again. The initial configuration of a user account and provisioning of software can be done via automation. The setting of the user account's respective password would be done automatically as well. This should be "change after first use". This automation process has to be reviewed regularly and has to be implemented with a four eyes principle.
Everything an admin does on a machine should be logged. If an admin just roams freely on a system before provisioning, 'bad admin'-scenarios are bound to happen.
Edit:
As this answer has stirred up some conversation, let me add the following:
Here are the some tools to provision Windows images to company hardware, for Windows 8 the Microsoft Deployment Toolkit and the System Center Configuration Manager for Windows 10. These tools are official Microsoft tools, they are free (as far as I can tell) and from frist glance pretty well documented. There you can implement and document all processes for provisioning Windows 8/10 on company hardware easily. All admin accesses to a machine should be done via tools like these and should be logged with a logging server. Then there are less possibilities for a single admin to manipulate a single machine.
If an admin handles every machine by hand, 1) manipulation is possible and 2) errors are bound to happen. An automated process can be reviewed and audited, a manual process is impossible to control.
The commitment to tools like these is a step towards a more secure provisioning of operating systems and user accounts in a company environment.
edited 13 hours ago
answered yesterday
Tom K.
5,03432047
5,03432047
How can the procedure such as setting up Outlook app on a person's laptop be automated? Also small companies do not always invest in automating. If a company hires around 10 staff per year the effort required to bring automation and maintain it will be greater than the manual effort.
– Kolappan Nathan
yesterday
1
To automate a 10 minute system config process will take far more than 10 minutes, and will definitely require a much more expensive System Admin. If you get an incompetent Admin to do the automation, best-case scenario is it'll not work. Worst-case scenario is they open up every system to vulnerabilities. You also need a manager that can tell the difference and knows how to hire for automation. It is a much more expensive endeavor. Ever tried making a custom Windows install disc with specific pre-installed drivers? It took me several hours the first time...
– Nelson
23 hours ago
@Nelson I'm not sure where you are getting at? According to this scientific chart(!), saving 30 minutes weekly (which I'm pretty sure that this task will take if I read OP right) one can invest 21 hours into this.
– Tom K.
21 hours ago
@KolappanNathan I don't know. I'm not a Windows Sysadmin, but I'm sure there's a way.
– Tom K.
21 hours ago
I can assure you 21 hours of automation will last maybe 1 month, then you'll have to do it again when new things come out. It's a lot more complicated if the company is not running a dumb terminal. Different departments, different software packages, etc. It is a massive amount of time, and it changes, at minimum, yearly, across every department.
– Nelson
20 hours ago
|
show 6 more comments
How can the procedure such as setting up Outlook app on a person's laptop be automated? Also small companies do not always invest in automating. If a company hires around 10 staff per year the effort required to bring automation and maintain it will be greater than the manual effort.
– Kolappan Nathan
yesterday
1
To automate a 10 minute system config process will take far more than 10 minutes, and will definitely require a much more expensive System Admin. If you get an incompetent Admin to do the automation, best-case scenario is it'll not work. Worst-case scenario is they open up every system to vulnerabilities. You also need a manager that can tell the difference and knows how to hire for automation. It is a much more expensive endeavor. Ever tried making a custom Windows install disc with specific pre-installed drivers? It took me several hours the first time...
– Nelson
23 hours ago
@Nelson I'm not sure where you are getting at? According to this scientific chart(!), saving 30 minutes weekly (which I'm pretty sure that this task will take if I read OP right) one can invest 21 hours into this.
– Tom K.
21 hours ago
@KolappanNathan I don't know. I'm not a Windows Sysadmin, but I'm sure there's a way.
– Tom K.
21 hours ago
I can assure you 21 hours of automation will last maybe 1 month, then you'll have to do it again when new things come out. It's a lot more complicated if the company is not running a dumb terminal. Different departments, different software packages, etc. It is a massive amount of time, and it changes, at minimum, yearly, across every department.
– Nelson
20 hours ago
How can the procedure such as setting up Outlook app on a person's laptop be automated? Also small companies do not always invest in automating. If a company hires around 10 staff per year the effort required to bring automation and maintain it will be greater than the manual effort.
– Kolappan Nathan
yesterday
How can the procedure such as setting up Outlook app on a person's laptop be automated? Also small companies do not always invest in automating. If a company hires around 10 staff per year the effort required to bring automation and maintain it will be greater than the manual effort.
– Kolappan Nathan
yesterday
1
1
To automate a 10 minute system config process will take far more than 10 minutes, and will definitely require a much more expensive System Admin. If you get an incompetent Admin to do the automation, best-case scenario is it'll not work. Worst-case scenario is they open up every system to vulnerabilities. You also need a manager that can tell the difference and knows how to hire for automation. It is a much more expensive endeavor. Ever tried making a custom Windows install disc with specific pre-installed drivers? It took me several hours the first time...
– Nelson
23 hours ago
To automate a 10 minute system config process will take far more than 10 minutes, and will definitely require a much more expensive System Admin. If you get an incompetent Admin to do the automation, best-case scenario is it'll not work. Worst-case scenario is they open up every system to vulnerabilities. You also need a manager that can tell the difference and knows how to hire for automation. It is a much more expensive endeavor. Ever tried making a custom Windows install disc with specific pre-installed drivers? It took me several hours the first time...
– Nelson
23 hours ago
@Nelson I'm not sure where you are getting at? According to this scientific chart(!), saving 30 minutes weekly (which I'm pretty sure that this task will take if I read OP right) one can invest 21 hours into this.
– Tom K.
21 hours ago
@Nelson I'm not sure where you are getting at? According to this scientific chart(!), saving 30 minutes weekly (which I'm pretty sure that this task will take if I read OP right) one can invest 21 hours into this.
– Tom K.
21 hours ago
@KolappanNathan I don't know. I'm not a Windows Sysadmin, but I'm sure there's a way.
– Tom K.
21 hours ago
@KolappanNathan I don't know. I'm not a Windows Sysadmin, but I'm sure there's a way.
– Tom K.
21 hours ago
I can assure you 21 hours of automation will last maybe 1 month, then you'll have to do it again when new things come out. It's a lot more complicated if the company is not running a dumb terminal. Different departments, different software packages, etc. It is a massive amount of time, and it changes, at minimum, yearly, across every department.
– Nelson
20 hours ago
I can assure you 21 hours of automation will last maybe 1 month, then you'll have to do it again when new things come out. It's a lot more complicated if the company is not running a dumb terminal. Different departments, different software packages, etc. It is a massive amount of time, and it changes, at minimum, yearly, across every department.
– Nelson
20 hours ago
|
show 6 more comments
up vote
0
down vote
There seems to be a mistaken assumption here, that a portable PC owned by an employer and an e-mail account provided and paid for by an employer in some sense belong to the employee. They don't! The situation is that you are employed and paid to operate their equipment and to process their data. (Ditto, the sysadmins).
So the only way to be certain of privacy, is to handle private matters on hardware that you own personally. Your mobile phone connected to the mobile network is probably that device, while you are at work. If you employer allows personal use of its connection to the internet at large, secure (https) communication with a personal account on an external e-mail service such as Gmail is almost as safe -- just as long as you trust your employer not to do anything blatantly immoral such as installing a keystroke-logger on your employer-owned PC to intercept your private password and a screen recorder to allow the employer to watch your screen later. In the EU this would be blatantly illegal unless the employers policies (which you have been made aware of and which are part of your contract of employment) warn of such. It's likely to be illegal even if they do, unless you are working in a particularly sensitive environment (in which case all personal use of the employer's hardware is likely to be forbidden for sensible security reasons).
The sysadmins are paid by the employer to maintain its assets in accordance with its policies. These policies ought to comply with the law. So in the EU there is an expectation of privacy with respect to e-mails, hedged around with actions necessary for the employer to perform. So a sysadmin may have to look at "private" e-mails in order to administer a mail server system, but should not ever reveal or act on what he sees unless it reveals some serious misconduct or crime. He certainly should never deliberately look at e-mails outside the policies set by the employer and known to the employee.
But a bad or corrupt sysadmin is privileged, so there is nothing you can do to protect yourself from him. If you don't fully trust your employer, at a minimum don't use it's hardware for private purposes that would hurt you were they to be made public. At a maximum, you should be looking for a new job!
In passing, I'm a small-company sysadmin, and set up PCs pretty much as described. At a previous employer, it was s.o.p. to send a single e-mail from the newly configured PC to the the sysadmin's company e-mail account, reply to that, and delete the reply, to make sure everything was working well. It was also s.o.p. to send a longer e-mail from the sysadmin to the newly created employee's account, generally welcoming him to the organisation and providing standard information about getting started. It would be waiting for them after they logged in for the first time, resetting their password.
add a comment |
up vote
0
down vote
There seems to be a mistaken assumption here, that a portable PC owned by an employer and an e-mail account provided and paid for by an employer in some sense belong to the employee. They don't! The situation is that you are employed and paid to operate their equipment and to process their data. (Ditto, the sysadmins).
So the only way to be certain of privacy, is to handle private matters on hardware that you own personally. Your mobile phone connected to the mobile network is probably that device, while you are at work. If you employer allows personal use of its connection to the internet at large, secure (https) communication with a personal account on an external e-mail service such as Gmail is almost as safe -- just as long as you trust your employer not to do anything blatantly immoral such as installing a keystroke-logger on your employer-owned PC to intercept your private password and a screen recorder to allow the employer to watch your screen later. In the EU this would be blatantly illegal unless the employers policies (which you have been made aware of and which are part of your contract of employment) warn of such. It's likely to be illegal even if they do, unless you are working in a particularly sensitive environment (in which case all personal use of the employer's hardware is likely to be forbidden for sensible security reasons).
The sysadmins are paid by the employer to maintain its assets in accordance with its policies. These policies ought to comply with the law. So in the EU there is an expectation of privacy with respect to e-mails, hedged around with actions necessary for the employer to perform. So a sysadmin may have to look at "private" e-mails in order to administer a mail server system, but should not ever reveal or act on what he sees unless it reveals some serious misconduct or crime. He certainly should never deliberately look at e-mails outside the policies set by the employer and known to the employee.
But a bad or corrupt sysadmin is privileged, so there is nothing you can do to protect yourself from him. If you don't fully trust your employer, at a minimum don't use it's hardware for private purposes that would hurt you were they to be made public. At a maximum, you should be looking for a new job!
In passing, I'm a small-company sysadmin, and set up PCs pretty much as described. At a previous employer, it was s.o.p. to send a single e-mail from the newly configured PC to the the sysadmin's company e-mail account, reply to that, and delete the reply, to make sure everything was working well. It was also s.o.p. to send a longer e-mail from the sysadmin to the newly created employee's account, generally welcoming him to the organisation and providing standard information about getting started. It would be waiting for them after they logged in for the first time, resetting their password.
add a comment |
up vote
0
down vote
up vote
0
down vote
There seems to be a mistaken assumption here, that a portable PC owned by an employer and an e-mail account provided and paid for by an employer in some sense belong to the employee. They don't! The situation is that you are employed and paid to operate their equipment and to process their data. (Ditto, the sysadmins).
So the only way to be certain of privacy, is to handle private matters on hardware that you own personally. Your mobile phone connected to the mobile network is probably that device, while you are at work. If you employer allows personal use of its connection to the internet at large, secure (https) communication with a personal account on an external e-mail service such as Gmail is almost as safe -- just as long as you trust your employer not to do anything blatantly immoral such as installing a keystroke-logger on your employer-owned PC to intercept your private password and a screen recorder to allow the employer to watch your screen later. In the EU this would be blatantly illegal unless the employers policies (which you have been made aware of and which are part of your contract of employment) warn of such. It's likely to be illegal even if they do, unless you are working in a particularly sensitive environment (in which case all personal use of the employer's hardware is likely to be forbidden for sensible security reasons).
The sysadmins are paid by the employer to maintain its assets in accordance with its policies. These policies ought to comply with the law. So in the EU there is an expectation of privacy with respect to e-mails, hedged around with actions necessary for the employer to perform. So a sysadmin may have to look at "private" e-mails in order to administer a mail server system, but should not ever reveal or act on what he sees unless it reveals some serious misconduct or crime. He certainly should never deliberately look at e-mails outside the policies set by the employer and known to the employee.
But a bad or corrupt sysadmin is privileged, so there is nothing you can do to protect yourself from him. If you don't fully trust your employer, at a minimum don't use it's hardware for private purposes that would hurt you were they to be made public. At a maximum, you should be looking for a new job!
In passing, I'm a small-company sysadmin, and set up PCs pretty much as described. At a previous employer, it was s.o.p. to send a single e-mail from the newly configured PC to the the sysadmin's company e-mail account, reply to that, and delete the reply, to make sure everything was working well. It was also s.o.p. to send a longer e-mail from the sysadmin to the newly created employee's account, generally welcoming him to the organisation and providing standard information about getting started. It would be waiting for them after they logged in for the first time, resetting their password.
There seems to be a mistaken assumption here, that a portable PC owned by an employer and an e-mail account provided and paid for by an employer in some sense belong to the employee. They don't! The situation is that you are employed and paid to operate their equipment and to process their data. (Ditto, the sysadmins).
So the only way to be certain of privacy, is to handle private matters on hardware that you own personally. Your mobile phone connected to the mobile network is probably that device, while you are at work. If you employer allows personal use of its connection to the internet at large, secure (https) communication with a personal account on an external e-mail service such as Gmail is almost as safe -- just as long as you trust your employer not to do anything blatantly immoral such as installing a keystroke-logger on your employer-owned PC to intercept your private password and a screen recorder to allow the employer to watch your screen later. In the EU this would be blatantly illegal unless the employers policies (which you have been made aware of and which are part of your contract of employment) warn of such. It's likely to be illegal even if they do, unless you are working in a particularly sensitive environment (in which case all personal use of the employer's hardware is likely to be forbidden for sensible security reasons).
The sysadmins are paid by the employer to maintain its assets in accordance with its policies. These policies ought to comply with the law. So in the EU there is an expectation of privacy with respect to e-mails, hedged around with actions necessary for the employer to perform. So a sysadmin may have to look at "private" e-mails in order to administer a mail server system, but should not ever reveal or act on what he sees unless it reveals some serious misconduct or crime. He certainly should never deliberately look at e-mails outside the policies set by the employer and known to the employee.
But a bad or corrupt sysadmin is privileged, so there is nothing you can do to protect yourself from him. If you don't fully trust your employer, at a minimum don't use it's hardware for private purposes that would hurt you were they to be made public. At a maximum, you should be looking for a new job!
In passing, I'm a small-company sysadmin, and set up PCs pretty much as described. At a previous employer, it was s.o.p. to send a single e-mail from the newly configured PC to the the sysadmin's company e-mail account, reply to that, and delete the reply, to make sure everything was working well. It was also s.o.p. to send a longer e-mail from the sysadmin to the newly created employee's account, generally welcoming him to the organisation and providing standard information about getting started. It would be waiting for them after they logged in for the first time, resetting their password.
answered 16 hours ago
nigel222
1092
1092
add a comment |
add a comment |
up vote
0
down vote
You buy a new car. At least once a year you take it to mechanic for maintenance (oil check etc.). Most of us will give mechanic a key and went to do something (shopping, coffee, etc.). They have a complete access to your car. They can do anything. Do you consider it as a big problem alto you could leave/forget your private/office laptop inside or some personal documents or....??
Just as maintenance of your car, preparing your account is something that need to be done. You can sit by, watching and pretending that you know what they are doing or let them do it by themselves trusting them they are professionals and know what they are doing.
In case of moving to a new job, I would be more concerned about my full mailbox left on old job that empty one on a new job.
Being paranoid is quite OK, as long as you are sure you know why you are paranoid.
This remind me of a GDPR joke:
In the doctors office nurse comes out saying: "Due to GDPR I'm not allowed to say your names in public, but the one with syphilis can go to see doctor...."
New contributor
This does not answer the question and the analogy does not fit. The analogy would be "when buying a car, is it ok that the dealership had the keys first?"
– schroeder♦
15 hours ago
Wrong example! Having dealt too many times with non-professional mechanics I will now look with a different eye the IT guys!
– Diego Pascotto
14 hours ago
add a comment |
up vote
0
down vote
You buy a new car. At least once a year you take it to mechanic for maintenance (oil check etc.). Most of us will give mechanic a key and went to do something (shopping, coffee, etc.). They have a complete access to your car. They can do anything. Do you consider it as a big problem alto you could leave/forget your private/office laptop inside or some personal documents or....??
Just as maintenance of your car, preparing your account is something that need to be done. You can sit by, watching and pretending that you know what they are doing or let them do it by themselves trusting them they are professionals and know what they are doing.
In case of moving to a new job, I would be more concerned about my full mailbox left on old job that empty one on a new job.
Being paranoid is quite OK, as long as you are sure you know why you are paranoid.
This remind me of a GDPR joke:
In the doctors office nurse comes out saying: "Due to GDPR I'm not allowed to say your names in public, but the one with syphilis can go to see doctor...."
New contributor
This does not answer the question and the analogy does not fit. The analogy would be "when buying a car, is it ok that the dealership had the keys first?"
– schroeder♦
15 hours ago
Wrong example! Having dealt too many times with non-professional mechanics I will now look with a different eye the IT guys!
– Diego Pascotto
14 hours ago
add a comment |
up vote
0
down vote
up vote
0
down vote
You buy a new car. At least once a year you take it to mechanic for maintenance (oil check etc.). Most of us will give mechanic a key and went to do something (shopping, coffee, etc.). They have a complete access to your car. They can do anything. Do you consider it as a big problem alto you could leave/forget your private/office laptop inside or some personal documents or....??
Just as maintenance of your car, preparing your account is something that need to be done. You can sit by, watching and pretending that you know what they are doing or let them do it by themselves trusting them they are professionals and know what they are doing.
In case of moving to a new job, I would be more concerned about my full mailbox left on old job that empty one on a new job.
Being paranoid is quite OK, as long as you are sure you know why you are paranoid.
This remind me of a GDPR joke:
In the doctors office nurse comes out saying: "Due to GDPR I'm not allowed to say your names in public, but the one with syphilis can go to see doctor...."
New contributor
You buy a new car. At least once a year you take it to mechanic for maintenance (oil check etc.). Most of us will give mechanic a key and went to do something (shopping, coffee, etc.). They have a complete access to your car. They can do anything. Do you consider it as a big problem alto you could leave/forget your private/office laptop inside or some personal documents or....??
Just as maintenance of your car, preparing your account is something that need to be done. You can sit by, watching and pretending that you know what they are doing or let them do it by themselves trusting them they are professionals and know what they are doing.
In case of moving to a new job, I would be more concerned about my full mailbox left on old job that empty one on a new job.
Being paranoid is quite OK, as long as you are sure you know why you are paranoid.
This remind me of a GDPR joke:
In the doctors office nurse comes out saying: "Due to GDPR I'm not allowed to say your names in public, but the one with syphilis can go to see doctor...."
New contributor
New contributor
answered 15 hours ago
Kwisatz Haderach
1
1
New contributor
New contributor
This does not answer the question and the analogy does not fit. The analogy would be "when buying a car, is it ok that the dealership had the keys first?"
– schroeder♦
15 hours ago
Wrong example! Having dealt too many times with non-professional mechanics I will now look with a different eye the IT guys!
– Diego Pascotto
14 hours ago
add a comment |
This does not answer the question and the analogy does not fit. The analogy would be "when buying a car, is it ok that the dealership had the keys first?"
– schroeder♦
15 hours ago
Wrong example! Having dealt too many times with non-professional mechanics I will now look with a different eye the IT guys!
– Diego Pascotto
14 hours ago
This does not answer the question and the analogy does not fit. The analogy would be "when buying a car, is it ok that the dealership had the keys first?"
– schroeder♦
15 hours ago
This does not answer the question and the analogy does not fit. The analogy would be "when buying a car, is it ok that the dealership had the keys first?"
– schroeder♦
15 hours ago
Wrong example! Having dealt too many times with non-professional mechanics I will now look with a different eye the IT guys!
– Diego Pascotto
14 hours ago
Wrong example! Having dealt too many times with non-professional mechanics I will now look with a different eye the IT guys!
– Diego Pascotto
14 hours ago
add a comment |
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.
Diego Pascotto is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
14
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.
yesterday
5
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
yesterday
7
@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
yesterday
4
For those that argue about automation - you probably live in a dream-world. At least since Laptop-Vendors startet to use different hardware depending on pricing for the same laptop series, there is no guarantee an image will run on another laptop with the same config. Andere there are a myriad more pitfalls, where a certain username, windows update, combination of roles, ... could lead to new problems on the "same" hardware with the "same" automatic config.
– Falco
17 hours ago
2
@wizzwizz4: I'm not so silly as to disable the logs by running the command to disable logs. It's more like "started mmc.exe with elevated token".
– Joshua
12 hours ago