Password Security?
-
Also, I could actually forget the domain admin password. I'm not getting any younger!
Without wishing to sidetrack the thread too much: if you don't write the Domain Administrator password down, and only have an IT staff of one, what happens if that person dies or is terminated or otherwise becomes unavailable. Physically resetting the password? Is that best practice? It seems messy to me.
Also, you're an MSP aren't you? How do manage client domains if you don't write down any passwords?
-
What prevents the users from calling you when you reset their password? You could leave them a note something to the effect "I needed to login as you, your password was reset - please call me to get the new information"
-
Another "reason" I see is when you spin their password, their phone suddenly starts popping errors. When this is done because someone is out of town, how do you get them to log in and set their new password?
-
@Dashrender said:
What prevents the users from calling you when you reset their password? You could leave them a note something to the effect "I needed to login as you, your password was reset - please call me to get the new information"
I'm not always around. People work 24/7.
-
@JaredBusch said:
Another "reason" I see is when you spin their password, their phone suddenly starts popping errors. When this is done because someone is out of town, how do you get them to log in and set their new password?
Can they do it on their phones using OWA?
-
@scottalanmiller said:
@Carnival-Boy said:
Now, let's say you convince me of the risks. This brings me to the big problem I have with resetting a user password. People say "just reset it and let them know what it is and force them to change it when they logon." OK, how do I let them know? Some people say e-mail it to them.
How are you getting passwords to them now? Whatever works today should continue to work.
This is what I have done before at my last job. It doesn't actually reset the users password just generates a password based of the hash of there email and last four of social. I just had a excel sheet (encrypted) of what passwords are to be reset to when they are reset. Users would have to go to another persons computer and go to the internet to generate this. Though I think some eventually memorized their "reset" password. they would have to change it at next logon.
-
@Carnival-Boy said:
@JaredBusch said:
Another "reason" I see is when you spin their password, their phone suddenly starts popping errors. When this is done because someone is out of town, how do you get them to log in and set their new password?
Can they do it on their phones using OWA?
Nope. Has to be done from a domain joined computer.
-
@JaredBusch said:
Another "reason" I see is when you spin their password, their phone suddenly starts popping errors. When this is done because someone is out of town, how do you get them to log in and set their new password?
Depends on the work environment but, unless they are FLSA exempt the HR standard anymore is to not allow email outside working hours for them, as even if they choose to work on their own or are asked by their boss to check their email they still have to be paid for that time as a exempt employee. There have been law suits over this.
-
@Carnival-Boy said:
@scottalanmiller said:
How are you getting passwords to them now? Whatever works today should continue to work.
They are given it as part of their induction when they join the company. But that's not practical on a day to day level.
With a temp password, you can always give it in the same manner. It's a one time and you know when it has been used because it gets reset. Everyone needs a temp one now and then or a reset system. That's fine. But it should be generated from the IT side and the end user should always know if it has been used before (they would be unable to log in.)
-
@Carnival-Boy said:
@scottalanmiller said:
Why is the domain admin password written down? Is this a break-glass system for turning over admin access to a third party?
Essentially, yes. I've read tons of stories of networks getting compromised, usually as part of a penetration test. I haven't actually done a pen test here, but I've no doubt that our network could get compromised. What I haven't heard though, is networks getting compromised via a Keepass database (or similar password management tool). Those products seem pretty robust. That doesn't appear to be the weak link in our security.
Keepass is pretty secure. But how it is used is what matters. Are you the only one with access to it? If so, isn't that a point of fragility? If not, that's a lot of password exposure. Are you confident that no one is writing down the Keepass password?
Keepass is great, I just wouldn't keep the one master domain password there.
-
@Carnival-Boy said:
Also, I could actually forget the domain admin password. I'm not getting any younger!
Without wishing to sidetrack the thread too much: if you don't write the Domain Administrator password down, and only have an IT staff of one, what happens if that person dies or is terminated or otherwise becomes unavailable.
I'm of the opinion that there should never be only one domain admin. There should be someone, somewhere (could be the attorney) who keeps a backup account who is never, ever allowed to use it unless to terminate you or to deal with your demise. It's effectively a break-glass.
An organization much larger simply has a domain admin team. It's easy when you are bigger. But the CEO or Corporate Counsel or someone very senior, very trusted and very not involved should have a means to gain access in case of emergency.
We have an emergency break-glass that goes through a third party to get a sealed password for a one time emergency. We would have to reset the glass afterwards. But there is no casual way to get that access. You'd need a conspiracy to do it.
-
@Carnival-Boy said:
Also, you're an MSP aren't you? How do manage client domains if you don't write down any passwords?
Sometimes we have to, but we do as few as possible and we never keep people's passwords. We try our best to have user accounts on client systems, not shared accounts.
-
@Carnival-Boy said:
@Dashrender said:
What prevents the users from calling you when you reset their password? You could leave them a note something to the effect "I needed to login as you, your password was reset - please call me to get the new information"
I'm not always around. People work 24/7.
Why do you need to log in "as them"? If they know you will be working on it, and specifically need to be logged in as them to make the fix (say to their profile), then you can prep them by telling them, if you are not around when I make this change I will reset your password. This will break your phone's email until you change the password again and reset it on your phone as well."
Are there reasons you would need to be on a user's computer where they wouldn't be aware of it? And if so, do you really need to log in as them? If so, that sounds shifty to me.
-
How does your break-glass system work? I'm not sure whether it's a good idea to publish my security policy on a public forum, but sod it. I may delete this post in a couple of days:
I have 3 Domain Admin accounts. One is for my use. One is used by our MSP (which they write down, I don't know where they write it down exactly), and one is for emergency use (eg I get run over by a bus). The emergency one is stored in Keepass. Two other people have access to the Keepass database, and the Keepass password is written down (yes, it is written down!) and stored in the safe.
I used to just store the Domain Admin password in the safe, but it occurred to me that we have lots of other accounts that would be a real pain to recover if I ever disappeared. So it seemed better to just give my emergency users access to my Keepass file - that way they have everything.
If you use your attorney (as in your example), how do they remember the password without writing it down?
The Domain Admin accounts are configured to e-mail me whenever they are used, so if they are ever used when I'm not expecting them to be, it immediately arouses my suspicion and I may go into lock-down mode.
I'd be interested in any improvements to this. I don't like writing anything down, but I just haven't figured out a way of working without it (yet) and nothing on this thread has so far demonstrated how I can get away without writing anything down.
-
In a smaller environment, there can be lots of reasons why logging in as users would be desired, if not desirable. There is little other way to really test setup, for example. If you have power users, you probably never need this. Internally at NTG, for example, you never need to log in as someone else, ever. Because we can move icons around for ourselves and do other basic tasks. We know how to screen share when that is needed.
Non-technical end users very often need a degree of hand holding that actually results in doing things on their behalf. While that can be automated and done in a way that does not require a password, it is extremely hard. The smaller the environment, the more of a pain it is to work around. The issue that @Carnival-Boy is facing is real, the need to log in as them very commonly does exist. It's not good, but it is real and sadly there is no good way around this on Windows.
If this was Linux, the solution is simple. This is really a combination of Windows limitations combined with user deficiencies.
-
@Dashrender said:
Are there reasons you would need to be on a user's computer where they wouldn't be aware of it? And if so, do you really need to log in as them? If so, that sounds shifty to me.
Could be for shifty reasons, of course, but what we see is a huge desire to have people (IT) fixing end user machines or software when the end user is busy elsewhere. The last thing that you want to be doing is basic work while they are waiting, tied up or looking over your shoulder.
-
@Carnival-Boy said:
I have 3 Domain Admin accounts. One is for my use. One is used by our MSP (which they write down, I don't know where they write it down exactly), and one is for emergency use (eg I get run over by a bus). The emergency one is stored in Keepass. Two other people have access to the Keepass database, and the Keepass password is written down (yes, it is written down!) and stored in the safe.
Ah ha, I think that this is a better description than you first gave. Having your KeePass as the emergency holder of the domain admin account is better. I would think about improving that with a critical password used only for central "hit by a bus" passwords and keeping everything used regularly in a different database. Keepass does that easily.
-
@scottalanmiller said:
Could be for shifty reasons, of course
I'm not shifty, honest
I always have a backlog of minor helpdesk tickets that are often user profile related. Partly to offer the least inconvenience to users and partly because I'm a sucker, I mostly do these kinds of tickets after hours when everyone has gone home. Whilst most of my colleagues are at home watching the telly and sipping a beer, I'm often still at work, alone, fixing their minor bugbears.
The other advantage is that if the user isn't around, I'm not under any time pressure to complete the job. So I might be working on several jobs at once.
I also don't normally know exactly when I'll work on the ticket, so I can't let users know in advance, it depends on my workload, and whether I can bothered to stay late. An unexpected bit of warm weather and bright sunshine will normally see me finish early and head to a beer garden, leaving my helpdesk schedule in tatters.
-
I appreciate that a lot of my workflow is done out of convenience (either personal or user) rather than necessity. I don't have to work out of hours. I don't have to go to the pub instead of working.
But I'm still waiting to hear the actual risks of my workflow. Where's the harm? Only when I fully understand that can I balance risk against convenience.
-
@Carnival-Boy said:
@scottalanmiller said:
Could be for shifty reasons, of course
I'm not shifty, honest
I always have a backlog of minor helpdesk tickets that are often user profile related. Partly to offer the least inconvenience to users and partly because I'm a sucker, I mostly do these kinds of tickets after hours when everyone has gone home. Whilst most of my colleagues are at home watching the telly and sipping a beer, I'm often still at work, alone, fixing their minor bugbears.
The other advantage is that if the user isn't around, I'm not under any time pressure to complete the job. So I might be working on several jobs at once.
I also don't normally know exactly when I'll work on the ticket, so I can't let users know in advance, it depends on my workload, and whether I can bothered to stay late. An unexpected bit of warm weather and bright sunshine will normally see me finish early and head to a beer garden, leaving my helpdesk schedule in tatters.
This is what gets us. It's often best to work on user machines during the night when they are not around. Way more productive for IT and for the end users.
