End User Software Management When Running as Normal Users on Windows
-
@Dashrender said:
sure, to the local admin account. But that has nothing to do with JB's (and my) approach.
Our approach uses a domain account that would have assigned local admin privileges. This is no different than the Domain Admin account. If these accounts are at risk, then all accounts in a domain are at risk.
I do completely understand setting the local admin accounts to different passwords, preventing an attacker from walking your network from machine to machine through a local account that would typically bypass logging that a domain account would have.
Plus isn't there a concern of giving anyone that password. I guess if you absolutely trust the people you give the PDF to. But people always take the easy way out. I would assume never giving non-IT that password would be best practice.
-
@BRRABill Giving that PDF is no different than giving helpdesk personal the ability to look up the passwords in AD as LAPS allows those with permissions.
My thought wasn't to give the domain based account password to anyone. It would be used to save the credentials for locally launching an app that requires local admin access.
-
My point is that giving anyone access to circumvent the system seems to weaken it.
-
@BRRABill said:
My point is that giving anyone access to circumvent the system seems to weaken it.
You cannot have perfect security. That is a myth. There is no such thing as perfect.
Even near perfect security is a system that is useless to being used.
-
The solution of the domain account and using saved creditials on needed machines kept anyone from knowing the password.
the other option where supervisors have a sheet with it.. that's a business decision, not really an IT one.
-
We don't give anyone local admin rights. Tried published software before but it sucks.. I might look into a chocolate repo and a web interface that ties to PSexec to install the software to the computer the user visiting the webpage is on.
-
@Dashrender said:
@Brett said:
@JaredBusch said:
@Mike-Davis said:
@JaredBusch said:
As an outsourced IT Service Provider, we cannot be always available to clients to handle this need in as timely a fashion as needed at times (i.e. the owner says he needs his cat pics screensaver installed now).
The compromise we have come up with is a domain account that is added to the local administrators group in AD.
I'm in the boat and also use group policy to push a local admin account to the machines through group policy. If a machine (esp laptops) decides it doesn't want to log in to the domain, you can just log in with the local account and get it going.
Yeah, we push that LocalAdmin via GPO. It is not manually setup on the machines.
Consider changing this practice. I used to do it that way, too, but it's no longer considered secure and Microsoft won't even allow you to do it anymore in the newer versions of Windows Server in the GPPs.
So I read through the LAPS you linked to.. and I have to ask.. What's the difference between JB's creating a specific account and granting that account local admin and the fact that by default domain admin group is added to the local administrators group on every PC on the domain?
LAPS is more about the local admin account password being set the same on every machine, but JB's solution isn't the local admin account, it's a domain account that's granted local admin access.
I have done what LAPS is meant to replace - use GPO to set the local admin password to a specific password, and your point about it applying to more than just workstations is well received. I'm going to look into LAPS. Thanks.
I don't think I fully understood what Jared was saying.I replied to his line about pushing a "local admin" account via group policy without thoroughly looking at his earlier posts with the screenshots. I didn't realize he meant pushing a domain account named local admin.
What you don't want to do is create local accounts via GPPs because the passwords aren't stored securely. This is where LAPS helps because it gives a local account on each workstation a random password every so many days that's stored in AD. Also note that you can assign it to any account. For instance, I leave the builtin administrator account disabled but create a new local admin named "LocalAdmin" as part of the provisioning process. Then LAPS changes its password regularly for me.
But as far as pushing a domain user (or security group) into the workstations' local administrators group, I don't think there's anything wrong with that. My only word of caution would be to only use that account for workstation administration so that an attacker can't pass the hash into more significant systems.
Through a GPO I prevent the workstation admin security group from having logon rights to server systems and vice versa for the server admin security group. With PDQ Inventory and Deploy I use accounts that are restricted to logon as batch or service since there's no need for interactive logon.
It really all comes down to having only the rights that are necessary for the task.
-
Also please note that you do not want LAPS to apply to domain controllers since they have no local accounts. It will change the domain's Administrator account password. I found that out while testing LAPS.
I still use it on servers, just not DCs.
-
@Brett said:
Also please note that you do not want LAPS to apply to domain controllers since they have no local accounts. It will change the domain's Administrator account password. I found that out while testing LAPS.
I still use it on servers, just not DCs.
Doh! it changes Domain Admin accounts - that's not cool. Though, I guess this means that your domain admin account name was the same as the local account? or are you talking specifically about the Administrator account?
I've changed the name of my Domain Administrator account so that's not an issue.
-
@Dashrender said:
@Brett said:
Also please note that you do not want LAPS to apply to domain controllers since they have no local accounts. It will change the domain's Administrator account password. I found that out while testing LAPS.
I still use it on servers, just not DCs.
Doh! it changes Domain Admin accounts - that's not cool. Though, I guess this means that your domain admin account name was the same as the local account? or are you talking specifically about the Administrator account?
I've changed the name of my Domain Administrator account so that's not an issue.
Yes, you're exactly right. So, as I'm sure you know but just to be clear, by default the built-in Administrator account is named Administrator on all Windows and Windows Server OSes. And when you upgrade a server to become a DC for the first time in an environment it converts that built-in Administrator account into the domain's Administrator account, and it's still named Administrator. (So suddenly you go from using ServerName\Administrator to the all-powerful NetBIOSDomainName\Administrator with the same password the first time you create a DC.)
LAPS by default changes the account named Administrator, whether it's just a local built-in account on a workstation or server or the domain account. So if you haven't changed LAPS away from the defaults and you haven't changed your built-in Administrator account (either on a workstation or on the DCs) it will change their password.
I like to leave the built-in Administrator accounts alone on the workstations. They're disabled by default and when you first install Windows it has you create an alternative local admin account anyway. So I figure there's some purpose behind that. Plus, I've read that even if you rename the built-in Administrator account it's trivial for attackers to find them b/c their SID is unique and stays the same no matter what the name is changed to. It's another example of how security through obscurity doesn't really work. So that's why I opt to leave them disabled and create an account named LocalAdmin instead and I change the LAPS policy to target these for password changes.
Regarding the built-in domain administrator account named Administrator, I generally leave it in the hands of my clients, as an in-case-of-emergency-use-this-account. But for everyday administration it's never touched. So I just don't apply the LAPS GPO to the DC OU to be absolutely sure, but by the fact that I have the LAPS policy changed to target accounts named LocalAdmin it shouldn't affect them anyway.
I hope that made sense!
-
@Brett said:
I like to leave the built-in Administrator accounts alone on the workstations. They're disabled by default and when you first install Windows it has you create an alternative local admin account anyway. So I figure there's some purpose behind that.
I'm guessing they are there for legacy support, nothing more.
As for the system having you make a new one when you first install Windows - do they? I haven't see that. What I mean is - sure Windows has you make a new account but they in no way tell you it's a local admin account, which is just sad! Even Apple has you create an admin account and I'm pretty sure right after that they make you make an non-admin account for daily use.
So, yeah the first new account created is an admin account, but this in now way helps the user to have a more secure environment, but most will never create a second account.
I typically don't enable the local admin account either. I do have GPO change it's password to something, so that process could be changed to use LAPS. I also have my GPO remove the during install created user from the local admin group (really it removes everything that I don't explicitly allow). Then I have it add my global Domain PC Admin group to the local Admins group.
-
@Brett said:
Plus, I've read that even if you rename the built-in Administrator account it's trivial for attackers to find them b/c their SID is unique and stays the same no matter what the name is changed to. It's another example of how security through obscurity doesn't really work. So that's why I opt to leave them disabled and create an account named LocalAdmin instead and I change the LAPS policy to target these for password changes.
I have heard that finding the admin account through the SID is trivial. So I'm wondering, is your newly added account also trivially found via SID? If so, potato - potato... but if not, then cool, you've gained some small amount of security.
-
@Dashrender said:
@Brett said:
Plus, I've read that even if you rename the built-in Administrator account it's trivial for attackers to find them b/c their SID is unique and stays the same no matter what the name is changed to. It's another example of how security through obscurity doesn't really work. So that's why I opt to leave them disabled and create an account named LocalAdmin instead and I change the LAPS policy to target these for password changes.
I have heard that finding the admin account through the SID is trivial. So I'm wondering, is your newly added account also trivially found via SID? If so, potato - potato... but if not, then cool, you've gained some small amount of security.
I think that it can be found easily. What I'm not sure is if it can be identified as the admin account easily.
-
@scottalanmiller I think the only SID that can be easily identified as and admin account is the default Administrator account.
-
Boy that's pretty sad if the SID of the local admin is either static across all Windows machines, or if not static is somehow easy for non admin users of the system to discover that fact - that seems wrong..
-
@brianlittlejohn said:
@scottalanmiller I think the only SID that can be easily identified as and admin account is the default Administrator account.
That's what I've always believed.
-
@Dashrender said:
Boy that's pretty sad if the SID of the local admin is either static across all Windows machines, or if not static is somehow easy for non admin users of the system to discover that fact - that seems wrong..
Same on UNIX. Common UID (UNIX SID) across all OSes.
-
A list of well known SID info:
-
@Brett Depending on what FFL or DFL you are on, you won't even be able to use GPP to create a user because of the lack of password access in newer versions. I tried and it wouldn't work because I had to have a password per the policy but I couldn't add one per the change in GPP. The workaround was a script that I have for new machines that adds a local account via GPO startup script then adds it to the local administrators group. The new PC stays in a temporary OU for a few things to be installed, then moved to the permanent OU where the remaining items are run, including the installation of LAPS, which then changes the newly-created local admin password.
Here is the bat file that is called in the startup:
net user "My Admin" mypassword /add /passwordreq:yes /fullname:"My Admin"
net localgroup Administrators "My Admin" /add
