|
PUBLIC TOILET posted:I haven't Googled this but I thought I'd ask here first: Yep. What a snipe. I got nothing. 
|
#
?
Jan 28, 2019 15:56
|
|
|
|
| # ? May 29, 2024 02:46 |
|
|
So, speaking of Hyper-V. I'm doing some testing with DHCP and PXE with some VMs on my work machine. I've got my NIC setup as a "bridged" switch so my VMs are on the same network as my physical machine. I want to be able to sniff all the traffic my VMs are generating with wireshark. I've found lots of information on port-mirroring where I can set a VM as the "source" and another VM as the "destination" and I've even found how to use Hyper-V host as the "source" and a VM as the "destination" but I can't find a way to use a VM as the "source" and the physical NIC as the "destination." I found this: https://cloudbase.it/hyper-v-promiscuous-mode/ I want the monitormode to be 1 instead of 2, but I can't do that just by changing the number from 2 to 1. I tried the module there and it also failed. This seems simple but maybe I'm missing something? I basically just want to capture all traffic that touches my virtual switch.
|
|
#
?
Jan 29, 2019 05:25
|
|
|
I am just bad at Windows or is this just stupid complicated? I have a program that needs to modify the AD Schema and needs terrible Enterprise Administrator Credentials. I'm a user with domain administrator, the program is in my downloads folder and I need to run this with parameters. When I open command prompt with "As another user" I get access denied to that folder which makes sense - what the hell am I missing? All my google results are insanely complicated with RunAs-Powershell Jobs. Also, is there still a need for Domain Users to be apart of the local admins on the local machine?
|
|
#
?
Jan 31, 2019 04:12
|
|
|
Tab8715 posted:I am just bad at Windows or is this just stupid complicated? That does sound odd. Can you try taking it out on your user profile (out of downloads and to a temp folder on C) and try running it as the enterprise admin creds then? And... Ah... No? Domain Users in local admins means that everyone is a local admin on that machine.
|
|
#
?
Jan 31, 2019 06:55
|
|
|
Tab8715 posted:Also, is there still a need for Domain Users to be apart of the local admins on the local machine? holy gently caress, no absolutely not good god run away
|
|
#
?
Jan 31, 2019 07:17
|
|
|
H2SO4 posted:holy gently caress, no absolutely not good god run away Why do I keep seeing this from time to time? Was there some reason in the past to do this?
|
|
#
?
Jan 31, 2019 07:21
|
|
|
Tab8715 posted:Why do I keep seeing this from time to time? Was there some reason in the past to do this? Laziness. Usually someone felt the need to be logging onto multiple machines (either a nosy boss or a piss-poor IT guy) and couldn't wrap their brain around role based administration.
|
|
#
?
Jan 31, 2019 07:40
|
|
|
For a long time many Windows apps wouldn't run without admin rights. Since then, lovely programmers still can't get it right. I have 2 main line of business apps where the vendors tell me that end users need to be local admin. They don't and those vendors are dumb and I have to argue with them every time I need support.
|
|
#
?
Jan 31, 2019 07:51
|
|
|
Tab8715 posted:Why do I keep seeing this from time to time? Was there some reason in the past to do this? It was pretty normal pre 2005 because applications wouldn't run without it. It used to be pretty common for them to store state information right in "c:\program files\whatever" and if the end user didn't have write rights in that directory you'd either get endless error messages or configuration changes were reset every restart. Only after Vista made this harder because of UAC did developers start putting the end user writable files into %appdata%. And yeah, I actually had this discussion with the solo-developer of a pension fund application in loving 2017 that he couldn't put his .mdb files that he needs to open with read/write rights in the program files directory.
|
|
#
?
Jan 31, 2019 10:44
|
|
|
Everyone in the company I work for are all local admins. Shrug.
|
|
#
?
Jan 31, 2019 13:48
|
|
|
The group that really confuses me is “Power Users”, like Windows tells me it’s for old applications but I’ve never actually encountered a program that required Power User membership. I do remember the old days of “Local admins... local admins everywhere!” mostly because doing its still a standard practice at the lovely little MSP I work at. 
|
|
#
?
Jan 31, 2019 13:58
|
|
|
GreenNight posted:Everyone in the company I work for are all local admins. Shrug. There's a big difference between everyone being an admin on their workstation (not best practice under most circumstances, but not the end of the world and the risk is manageable) and Domain Users having admin to every workstation (aww hell no).
|
|
#
?
Jan 31, 2019 15:24
|
|
|
AreWeDrunkYet posted:There's a big difference between everyone being an admin on their workstation (not best practice under most circumstances, but not the end of the world and the risk is manageable) and Domain Users having admin to every workstation (aww hell no). Its all subjective but I don't believe that everyone having admin on their computer is manageable risk. Saying that, I don't think anyplace where that is a norm is actually attempting to manage risk though.
|
|
#
?
Jan 31, 2019 15:26
|
|
|
In my previous position at a university all staff and faculty had local admin on their own PCs. I didn't like it, but it was an entrenched policy and I certainly didn't have the power to tell a bunch of tenured faculty that they couldn't install various accounting/research/CAD applications that they needed to do their job and that we didn't have the resources to support/deploy/etc anyway. So it made a certain about of sense in that particular environment, despite my misgivings about it. I'm pretty sure most universities are the same, though that's just from anecdotes during the one conference I went to while I worked there. Now I'm in a place that still has some rough edges but at least operates a software center and doesn't give admin to normal staff. I definitely prefer it this way.
|
|
#
?
Jan 31, 2019 15:45
|
|
|
95% of our users are standard users... But we have a handful of users that have local admin, but on their computer only. We use a Group Policy Preference that adds the user to the local built in administrators group, but also uses item level targeting via DNS name, so the GPP applies only to that user if they are logging onto their assigned computer. They are a standard user on any other machine. These users use an app where vendors ship catalog updates packaged into customized installers. One vendor can have upwards of 20+ different catalogs, one for each product line, each with its own custom installer. And they all need admin access to work.  I have tried so many times to get the things to work without admin, but every drat one is different. What works for one, doesn't work for others.
|
|
#
?
Jan 31, 2019 15:46
|
|
|
That seems perfectly reasonable. "domain users in local admin group lol" does not.
|
|
#
?
Jan 31, 2019 16:04
|
|
|
Sickening posted:Its all subjective but I don't believe that everyone having admin on their computer is manageable risk. Saying that, I don't think anyplace where that is a norm is actually attempting to manage risk though. Where I work we are not granted local admin access to our laptops, but you can petition for local admin if you want it. The process is incredibly simple: the ticket goes in with a statement by the user to the effect of “I know what I am doing and I want local admin. I understand that preserving my laptop’s data is now my responsibility. I further understand that if something goes wrong with it, desktop support will flatten/reinstall first and ask questions later.” The policy is remarkably effective.
|
|
#
?
Jan 31, 2019 17:42
|
|
|
Sickening posted:Its all subjective but I don't believe that everyone having admin on their computer is manageable risk. Saying that, I don't think anyplace where that is a norm is actually attempting to manage risk though. There is a huge difference between "User X has local admin on User X's PC" and "All users have local admin on all PCs". If User X infects their poo poo with malware in the first scenario it can rape that one machine all it wants but it can only spread to the rest of the network within User X's level of access the same as it could if they don't have local admin. In the second scenario it can spread throughout the entire network and easily use that level of access to gain execution under within other users' sessions by adding itself to one of the various startup autorun locations or just replacing a commonly used program. I don't like either situation, but one is at least containable where the other is just waiting for disaster. If a computer is only used by a single user and you're prepared to flatten it if it ever becomes questionable it's not the worst thing for that user to have local admin on that machine alone. All they can possibly gently caress up with that power is their own data. wolrah fucked around with this message at 18:12 on Jan 31, 2019 |
|
#
?
Jan 31, 2019 18:10
|
|
|
Docjowles posted:That seems perfectly reasonable. "domain users in local admin group lol" does not. My bad, I didn't mean the group "domain users" just users on the domain.
|
|
#
?
Jan 31, 2019 18:14
|
|
|
wolrah posted:There is a huge difference between "User X has local admin on User X's PC" and "All users have local admin on all PCs". That isn't true at all. An infected machine can infect others with no regard of that personas level of access to other machines. Once access is gained to the first machine it can then exploit vulnerabilities in others to execute code or aid in social engineering. While having admin access to just your machine isn't as bad as having admin access to all, it puts a lot of strain on hardening your environment in other places. Frankly, if everyone has admin access to their own machine I find it unlikely that people are really putting in the effort into other areas to mitigate risk.
|
|
#
?
Jan 31, 2019 18:15
|
|
|
Our users are local admins on their own machines, which is something we keep trying to take away to the consternation of the VP of IT. There's really no reason people should have local admin (I mean, we're the  massive), but then someone says, "Bu bu but what if someone calls in and they need like a program installed and like they can't?" OH NOES, THE END OF THE loving WORLD just push the installer from the content management system and close the ticket, you loving moron.As as result, we have overbearing security tools on our endpoints that run up 100% CPU and cause mystery calls that can't be solved by pushing the goddamn button. And Powershell is hard blocked because lol that's a sane security policy. Oh, and everyone wants a Mac now, because it means they can install Dropbox and not get hassled by IT. Oh, for further lulz, those of us who need access to servers have super user accounts, which is great. Separate account, separate perms, separate password (ideally). Until I find out half my teammates are using their SU accounts on their local workstations. CONGRATULATIONS, COLLEAGUES, YOU ARE THE PROBLEM.
|
|
#
?
Jan 31, 2019 18:25
|
|
|
Tab8715 posted:My bad, I didn't mean the group "domain users" just users on the domain. Ah, I suspect we all thought you meant the former, which is much more horrifying 
|
|
#
?
Jan 31, 2019 18:26
|
|
|
Sickening posted:That isn't true at all. An infected machine can infect others with no regard of that personas level of access to other machines. Once access is gained to the first machine it can then exploit vulnerabilities in others to execute code or aid in social engineering. While having admin access to just your machine isn't as bad as having admin access to all, it puts a lot of strain on hardening your environment in other places. Frankly, if everyone has admin access to their own machine I find it unlikely that people are really putting in the effort into other areas to mitigate risk. I was about to ask about the risk of being in local admins, I guess that answered my question. I didn't recognize the impact.
|
|
#
?
Jan 31, 2019 18:28
|
|
|
There's some industrial software taught in a couple courses here that requires all users to be in the local admin group, which means students in those courses have admin on a set of lab PCs. There haven't been any issues in the 3 years I've been supporting it, but it's only a matter of time. When I asked the developer if there was a way around giving everyone local admin they told me: "Just add students to the $productadmin group that's created when you install the software, then add that group to local admin." 
|
|
#
?
Jan 31, 2019 18:33
|
|
|
Sickening posted:That isn't true at all. An infected machine can infect others with no regard of that personas level of access to other machines. Once access is gained to the first machine it can then exploit vulnerabilities in others to execute code or aid in social engineering. While having admin access to just your machine isn't as bad as having admin access to all, it puts a lot of strain on hardening your environment in other places. Frankly, if everyone has admin access to their own machine I find it unlikely that people are really putting in the effort into other areas to mitigate risk. Correct, if we're talking about malware spreading by exploit. The thing is in most cases that doesn't really care what level of access "patient zero" has, it can usually spread just as well from an unprivileged account, so I don't consider that to be too relevant to discussions of local admin. I'm talking about the damage that can be done without any exploits necessary. If patient zero has a standard account with no special privileges then without some kind of unpatched vulnerability to exploit the malware can only spread or cause damage within the user's own account and those shared areas which they have been granted access to. If patient zero has local administrator privileges on just their own machine then the same malware can take over that entire machine but is still limited in its ability to spread within the network by the privileges of the user it's running as. This is dangerous with a shared machine because it could infect any other accounts that logged in to that machine and spread to the extent of their privileges, but if we're talking about dedicated hardware used by one person it's basically no worse than the first scenario as long as that machine is handled with care after infection. If they have local admin across the board, that malware can spread using C$ shares and the like to every machine in reach within seconds. --- IMO limited one user to one machine local admin is to be avoided but justifiable in some cases, giving all users local admin to any station is a  situation.
|
|
#
?
Jan 31, 2019 20:25
|
|
|
wolrah posted:If they have local admin across the board, that malware can spread using C$ shares and the like to every machine in reach within seconds. This is why I went with the setup I did... At first I had a group that was added to the local admins group. If I had a user who needed local admin, I added them to this group. Except it gave them local admin on any machine that was part of that group, and it also gave them access to the administrative shares (C$) on all machines! Doing it through a GPP with a Item level targeting restriction prevents this. They are standard user on any other system, including those accessed over the network. So no C$ access.
|
|
#
?
Jan 31, 2019 21:01
|
|
|
wolrah posted:Correct, if we're talking about malware spreading by exploit. The thing is in most cases that doesn't really care what level of access "patient zero" has, it can usually spread just as well from an unprivileged account, so I don't consider that to be too relevant to discussions of local admin. I'm talking about the damage that can be done without any exploits necessary. You are thinking way too narrowly. Once access is established on the first machine they can scan/exploit the machines around it at its leisure. An attacker is by no means bound to the initial exploit/whatever was used on the initial compromise.
|
|
#
?
Jan 31, 2019 21:09
|
|
|
Sickening posted:You are thinking way too narrowly. Once access is established on the first machine they can scan/exploit the machines around it at its leisure. An attacker is by no means bound to the initial exploit/whatever was used on the initial compromise. I don't see how this is relevant. How many network-based exploits actually depend on having high privileges on the attacking host? As far as I can think, only the ones that attack the target's kernel network stack and thus need to generate nonsensical packets with raw sockets. Those vulnerabilities are of course rare at this point and get treated as ultra-critical by the OS vendors so anyone who hasn't patched up has bigger problems than worrying about user privileges. Pretty much anything attacking an application on the remote host can be initiated without any special privileges. Aside from those rare cases where a kernel-level vulnerability has just been discovered and hasn't been patched yet, how does the user of a dedicated workstation having local admin make them more of a threat to anything else on the network? If they only have admin on their sole dedicated workstation that only they use, the only stuff that admin privilege allows them to gently caress up is their own. wolrah fucked around with this message at 16:15 on Feb 1, 2019 |
|
#
?
Feb 1, 2019 16:13
|
|
|
wolrah posted:I don't see how this is relevant. How many network-based exploits actually depend on having high privileges on the attacking host? As far as I can think, only the ones that attack the target's kernel network stack and thus need to generate nonsensical packets with raw sockets. Those vulnerabilities are of course rare at this point and get treated as ultra-critical by the OS vendors so anyone who hasn't patched up has bigger problems than worrying about user privileges. Pretty much anything attacking an application on the remote host can be initiated without any special privileges. That was my point. Companies that just give everyone local admin access isn't going to patch effectively, isolate endpoints, or anything of the other things to harden their environments. Minimizing risk isn't on their radar. The things you don't see as "relevant" definitely are and should be. Minimizing who is local admin on their machine is very relevant. Sickening fucked around with this message at 17:11 on Feb 1, 2019 |
|
#
?
Feb 1, 2019 17:09
|
|
|
wolrah posted:I don't see how this is relevant. How many network-based exploits actually depend on having high privileges on the attacking host? As far as I can think, only the ones that attack the target's kernel network stack and thus need to generate nonsensical packets with raw sockets. Those vulnerabilities are of course rare at this point and get treated as ultra-critical by the OS vendors so anyone who hasn't patched up has bigger problems than worrying about user privileges. Pretty much anything attacking an application on the remote host can be initiated without any special privileges.
|
|
#
?
Feb 1, 2019 17:16
|
|
|
wyoak posted:Dumping the cached SAM database requires admin credentials and PtH is gonna be one of the first things someone tries on a popped domain machine, so unless you can guarantee that no one besides the workstation user has ever logged in to that machine you're giving away a pretty big attack surface, and that's just the first thing that comes to mind I was tempted to crosspost his arguements into the infosec threads for things just like this but I don't exactly hate him that much.
|
|
#
?
Feb 1, 2019 17:19
|
|
|
Sickening posted:That was my point. Companies that just give everyone local admin access isn't going to patch effectively, isolate endpoints, or anything of the other things to harden their environments. Minimizing risk isn't on their radar. As a small enterprise (~10000 users) we definitely do all these things despite giving our users local admin access. We restrict user profile access, we don't allow the server or winrm services to run on workstations and a bunch of other things. Hell, when everyone else was freaking out about smb exploits last year we just shrugged because we were already protected. It's really not that hard to minimize risk if you need to live with local admins and any place with more than a handful of IT staff is definitely doing it.
|
|
#
?
Feb 1, 2019 17:51
|
|
|
Caf posted:As a small enterprise (~10000 users) we definitely do all these things despite giving our users local admin access. You give all your users admin rights? If so, no, you are not minimizing risk lmao.
|
|
#
?
Feb 1, 2019 17:52
|
|
|
wyoak posted:Dumping the cached SAM database requires admin credentials and PtH is gonna be one of the first things someone tries on a popped domain machine, so unless you can guarantee that no one besides the workstation user has ever logged in to that machine you're giving away a pretty big attack surface, and that's just the first thing that comes to mind I thought the SAM database for locally cached domain passwords was double-hashed exactly to protect against this?
|
|
#
?
Feb 1, 2019 18:27
|
|
|
I'm a bit rusty on the specifics of the various AD hashing scenarios but yeah you're right. Still, an attacker can dump the hashes and attempt offline cracks - is everyone who has logged on that workstation using a strong password? Also, if an attacker is on a live machine and someone logs in remotely (say, for desktop support), or if there's a process running as a service account, etc etc etc, those hashes are going to be exposed as well and they are vulnerable to PtH. At the very least an attacker is going to be able to impersonate the computer account - did someone do something dumb like include a service account password in a computer-facing GPO? Does the computer account have access to potentially sensitive info that a user account doesn't? Anyway, yeah, local admin privileges can expose more than just local resources.
|
|
#
?
Feb 1, 2019 19:36
|
|
|
I'm trying to find a good fit for this question but I can't seem to figure out any other thread to put it in: Does anyone know of a web filter program that would work with Windows that allows for a manual bypass feature? Sort of like a captive portal that you can acknowledge that you're on break before continuing to a website that we don't want people going to? We don't want to completely take away access to things like Facebook/Instagram/Whatever because it usually just leads to extra bathroom breaks or people coming back late from breaks. I'd actually rather people use social media messaging from their PC than their phone so at least we have a trail if they do something stupid. Sorry, but my web filtering experience is limited to binary answers (yes you can go here or no, you can't).
|
|
#
?
Feb 1, 2019 21:05
|
|
|
I'm not aware of anything like that.
|
|
#
?
Feb 1, 2019 21:06
|
|
|
I know of something that can check if people are going to the websites you define, and if so, pop up a message saying whatever you want and requiring an answer. It's outside the browser and not really related to networking, though.
|
|
#
?
Feb 1, 2019 21:39
|
|
|
tadashi posted:I'm trying to find a good fit for this question but I can't seem to figure out any other thread to put it in: I'd imagine any that allow for the use of a bypass code would do this. Just make the bypass code common knowledge. Not sure that's a great idea, but yeah.
|
|
#
?
Feb 1, 2019 21:42
|
|
|
|
| # ? May 29, 2024 02:46 |
|
|
I'm pretty sure there are filtering options that the end-user can bypass and just enter their own reason in, then their line manager can review the exemptions they've entered.
|
|
#
?
Feb 1, 2019 21:44
|
|
