Windows 10 October Update Can Now Disable Your Administrator Account

[mynameisjuan]

1 minute ago, LAwLz said:

What do you mean by "mirroring vs actually accessing an account" and how is that relevant how to things work in *nix?

When you run sudo you are running the command as if you had permission similar to root, not actually running it as root. Thats why root is disabled in nix machines but you can still sudo. The command su is where you use the actual root account. Where if you want to run as an admin on a windows machine you need to login as an admin and it ran from that account.

 

6 minutes ago, LAwLz said:

You do know that the Administrator account does not run everything with Administrator privileges, right? There is nothing special about the Administrator account.

Running something as the Administrator user, and running something with administrator privileges are two very, very different things.

"Run as admin" does not run something as the Administrator user.

I shouldnt have mentioned run as admin as I was comparing it sudo. I was referring to the UAC when being able to use and Admin account to run an action. 

 

11 minutes ago, LAwLz said:

Administrator is just a regular account with administrator privileges. It is not different in any way shape or form, other than being automatically created and disabled when you install Windows, to your average "Juan" account that has administrator privileges.

Administrator is not like root.

I know its nothing special, but for best practice it should not be used for many reasons including exploits or simply determining who made a change in a large enterprise as below:

 

13 minutes ago, LAwLz said:

2) Not sure what you mean. Are you saying each person in the IT department should have their own local account on every computer? I guess that could work, but seems like a big security risk. More users and passwords = higher risk of one being compromised, especially since they are stored locally on a computer other people have access to.

In large enterprises with many IT personnel, you have AD accounts for every user but if there is an Administrator account on a machine and its enabled and the entire staff knows the common admin password, they could login and make a change anonymously.  What if this was used to access HR information, CC information...etc... 

 

My last job has a GP that pushed disabled local admin account with our own password to each machine. So say when Windows lost domain rights we would have to renable our local accounts and login to rejoin it to the domain and then disable it. 

 

Its a form of logging in large businesses. You cant just have people making anonymous changes. 

 

19 minutes ago, LAwLz said:

3) Please, explain to me in detail how exploits target the Administrator account, and how that is a bigger threat than if you had an account called "Backup_Admin". Any half-assed exploit you have to worry about will just check which accounts exists, and which of them have administrator privileges before picking a target to attack. This is not the 90's. Malware is a bit more clever than to just assume a certain account is used (especially an account that's disabled by default) and then only try to attack that.

Exploits still target Administrator accounts for the people that have enabled them or left default passwords or hell, no password at all. At least creating Backup_Admin reduces the risk from random attacks. Dictionary attacks are still a thing (which is essentially what this change is to prevent)

 

It should apply to nix as well. Look at that dumb exploit with Macs not to long ago where you could just login to root as root with no password. There legit reasons to change the default account. 

[Nicnac]

tell me again how shitty osx is  

[LAwLz]

7 hours ago, leadeater said:

One password at a time? Do you mean by that as in being physically at the computer? Brute forcing a password is technically one password at a time regardless of how it is done unless you parallel thread it and split up something like a dictionary attack. 

 

But you do know you can still get a script to run on a standard user account trying passwords against the built-in administrator account, with or without the logged in user knowing. 

 

Not every attack is done by some super smart person or the scripts they make/find/use always that sophisticated, sometimes they aren't even trying to crack the account just get it locked out to be annoying. I've had instances where schools have requested account lockouts be disabled because students/classes are purposely being annoying and locking out their teachers accounts or other students, sometimes all you're doing is cleaning up shit so anything to prevent one less pile of shit to be cleaned up is good in my book.

Yes I mean as in being at the computer, typing it in by hand. That's the only way if you have a wide range of security in place, and the attacker don't have a login.

If the attacker does have a login, then they can just look up the database and see the account names.

 

You seem to be defending yourself against a type of attacker I don't even think exists. An attacker that is good enough to brute-force a good password (which will take hundreds if not thousands of years, even with a script) but not knowledgeable enough to look up the username of the account they are attacking.

And I am not sure why you're bringing up locking accounts, because the Administrator account is a local one and won't get locked out no matter how many times you type the password wrong. The computer won't poll the AD for checking credentials.

 

 

 

7 hours ago, mynameisjuan said:

When you run sudo you are running the command as if you had permission similar to root, not actually running it as root. Thats why root is disabled in nix machines but you can still sudo. The command su is where you use the actual root account. Where if you want to run as an admin on a windows machine you need to login as an admin and it ran from that account.

 

I shouldnt have mentioned run as admin as I was comparing it sudo. I was referring to the UAC when being able to use and Admin account to run an action. 

 

I know its nothing special, but for best practice it should not be used for many reasons including exploits or simply determining who made a change in a large enterprise as below:

Look, all this boils down to is that you believe knowing the username of an account with administrator privileges is a vulnerability. It isn't. The account name is not, and isn't meant to be, a line of defense. That's why anyone with access to the computer can freely look it up, even if they don't have admin privileges. Windows will gladly give anyone or any program who asks for it a list of all the usernames who has admin privileges on the machine, no questions asked.

 

And for that last part, I see that you snuck in "large enterprise", when I previously have specifically said "small businesses". Yes, you're right for large enterprises, but that's not what we're talking about.

 

 

7 hours ago, mynameisjuan said:

In large enterprises with many IT personnel, you have AD accounts for every user but if there is an Administrator account on a machine and its enabled and the entire staff knows the common admin password, they could login and make a change anonymously.  What if this was used to access HR information, CC information...etc...  

Again, I specifically mentioned small businesses in these posts:

10 hours ago, LAwLz said:

"never be used" is a strong word. There are reasons why you might want to use it. For example like I mentioned earlier, it is very useful as the default admin account used by IT staff in a small business environment.

8 hours ago, LAwLz said:

I disagree that you shouldn't login to the Administrator account. Home users shouldn't, but in a small to medium corporate environment I would even recommend it as a backup account.

And in this post I bought up

As for making changes anonymously, they can do that anyway if they have local admin privileges to a computer. The correct way of doing things is having a random password for each computer, and then have a system that logs which user requests to see the password and when. Pretty sure you can configure it to change the password once the computer has joined AD again, and that prevents reusing the same password at a later time. I briefly mentioned that here:

22 hours ago, LAwLz said:

It's widely used in small companies where they are big enough to have AD and some privilege management, but small enough that the IT people want to just be able to walk up to any computer unprepared, and login to a local admin account without having to look up some randomly generated password specific to that computer (which is the proper way of doing it). 

 

 

 

7 hours ago, mynameisjuan said:

My last job has a GP that pushed disabled local admin account with our own password to each machine. So say when Windows lost domain rights we would have to renable our local accounts and login to rejoin it to the domain and then disable it.  

Wait, how would that work exactly?

Your accounts were disabled, and the computer had lost connection to the AD server. How would you go about enabling your personal accounts?

 

7 hours ago, mynameisjuan said:

Exploits still target Administrator accounts for the people that have enabled them or left default passwords or hell, no password at all. At least creating Backup_Admin reduces the risk from random attacks. Dictionary attacks are still a thing (which is essentially what this change is to prevent) 

If you have a local administrator account with no password then that's not a security risk because someone knows the account name, it's a security risk because you're using a bad password. An account with the name Backup_Admin would be just as vulnerable to that because, like I said before, anyone who has access to the computer can look up the account name if they want. Account names are not secrets, and you should not rely on that to keep someone from accessing administrator privileges. That is a very, very dumb idea.

 

And I don't see how using a different account name would prevent dictionary attacks.

 

 

7 hours ago, mynameisjuan said:

It should apply to nix as well. Look at that dumb exploit with Macs not to long ago where you could just login to root as root with no password. There legit reasons to change the default account. 

Irrelevant to this conversation. That exploit would not have been prevented by having root disabled (which it is in MacOS), nor would it have been prevented if the root account had a different name.

[Guest]

11 hours ago, mynameisjuan said:

Dont enable and dont login to Administrator/Root accounts, thats it, thats the point. 

 

10 hours ago, leadeater said:

By default on Ubuntu server it's not actually possible to login as root or switch user to root without booting in to single user mode, sudo is all you should need. I mean it's a good model which is why Windows copied it and why UAC was created. UAC is the real security improvement not so much the leaving disabled of built-in administrator but you're still adding to security by also doing that.

Anyway I don't find what is the reason about comparing root with the windows administrator account, or even Windows Administrator group users, they work in a completely different way

There can't be a Linux system with root disabled, it still exist, it just it doesn't have a password so you can't access it directly via terminal, what some distros like Ubuntu do instead by default is just restricting direct access, and create sudo-enabled users, which are similar to Windows administrator-enabled accounts but you still need to re-type the password for every action, so the distinction is just about

root and users that can login as root by typing the user sudo password (wheel or sudo group), but still every sudo command just basically runs a program with the root user, instead on Windows you are into the administrator group which has basically administrator privileges

 

If you try to add yourself to the root group on Linux, like on Windows, it's just not gonna work and you don't have root permissions and neither able to run sudo if you are not into the wheel/sudoers group

 

Also, no one except root is able to read the hashed passwords in /etc/shadow (only on Linux) so your only way to access it is to have sudo privileges and know the sudo user password in Ubuntu 

(login screens are run as root so it definitely exist, even X.org is run as root, the init and it's daemons basically )

 

 

[yian88]

On 1/4/2019 at 5:01 PM, Ja50n said:

Linux gaming performance just needs to get a little bit better, then I can ditch Windows for good...

Sadly thats not going to happen, i only play online games and online games never come to linux, also port of games made for linux either dont have all DLC's or no DLC's at all or have no mod support, the only offline games i play are strategy games with mods civilization, Total War etc, these suck under linux 0 mods. I play a lot of diablo 3 which will never be supported under linux and i dont give a shit about steam's proton i need a generic solution that also works for online games with antihack protection and all antihack protections like gameguard are windows exclusive. 

So there is no hope for linux gaming, at least not online gaming.

Then there is the developing  side of linux you lack professional tools for everything, those that are paid you know. Also even free ones like UE4 sucks full of bugs under linux, has no Launcher, without it UE4 is pointless i cant install extra marketplace content which is very important for me, and how many games released with UE4 have ever released a linux version even tough the engine support linux builds right from the start? Fortnite? no, PUBG? no, Lost Ark? no, you get the point, no one releases games for linux even if the engine supports it by default, same for Unity good luck finding a popular unity game that has a linux version released, the <1%...

[Guest]

2 hours ago, yian88 said:

Then there is the developing  side of linux you lack professional tools for everything, those that are paid you know. Also even free ones like UE4 sucks full of bugs under linux, has no Launcher, without it UE4 is pointless i cant install extra marketplace content which is very important for me, and how many games released with UE4 have ever released a linux version even tough the engine support linux builds right from the start? Fortnite? no, PUBG? no, Lost Ark? no, you get the point, no one releases games for linux even if the engine supports it by default, same for Unity good luck finding a popular unity game that has a linux version released, the <1%...

Uhh honestly I developed myself a couple of Unity project and the IDE wasn't that bugged, I once run UE4 too, and I didn't find a single issue, except the usual ones that also happen on Windows 

An alternative to Proton is Lutris, depending on the script it could even include the Proton own wine version with all the fixes in there also for non-steam games

I think some time in the future wine could gain more importance instead of native linux ports, I mean, currently DXVK in 1 year has done more than developers releasing poor linux ports in a decade especially from a performance standpoint the difference in frame per seconds is very little, and it is just an alpha

10 years ago if you said "in the future you could run DX11 games on linux this easily and with a little performance drop" they would treat you like crazy, you can't tell what's going on in the future

Wine also includes compatibility for other programs than games like the adobe suite for example, and huuh just saying maybe in the future the compatibility would be almost perfect, definitely a thing to increase market share and hope for more native ports (or even if windows apps would be running perfectly fine and seamless)
 
The anticheat engines for wine are the big issue currently as EAC for example uses a Windows driver, and there is no translation currently in Wine for Windows drivers.

[Sauron]

On 1/4/2019 at 5:52 PM, samcool55 said:

Disabling root so you can't use it at all is a really bad idea in most cases. I get that enabling the admin on windows isn't a good idea, but i can see it making sense when you have it enabled and use it only when you need it (run as a different user is a thing soo...).

I think the comparison between root and Administrator breaks down here... root actively does things in Linux that are necessary for the system to work. Privileged services and much more are run as root, even if you have a "sudoer" account. Furthermore, whenever you do something as superuser in Linux, you're actually asking root to do it, whereas in Windows the Administrator account isn't called every time you click "run as administrator" (at least as far as I know - otherwise disabling the account would break that functionality).

[Guest]

1 minute ago, Sauron said:

I think the comparison between root and Administrator breaks down here... root actively does things in Linux that are necessary for the system to work. Privileged sefvices and much more are run as root, even if you have a "sudoer" account. Furthermore, whenever you do something as superuser in Linux, you're actually asking root to do it, whereas in Windows the Administrator account isn't called every time you click "run as administrator" (at least as far as I know - otherwise disabling the account would break that functionality).

That's what I said too, if you just type "sudo whoami" the output will result in "root" even if Ubuntu got the root account without direct access

[leadeater]

3 hours ago, Lukyp said:

Anyway I don't find what is the reason about comparing root with the windows administrator account, or even Windows Administrator group users, they work in a completely different way

There can't be a Linux system with root disabled, it still exist, it just it doesn't have a password so you can't access it directly via terminal, what some distros like Ubuntu do instead by default is just restricting direct access, and create sudo-enabled users, which are similar to Windows administrator-enabled accounts but you still need to re-type the password for every action, so the distinction is just about

Correct though we are talking more about the security model not the functionality of the account itself, not using a well known account and not running with admin prviledges all the time.

 

To that similar extent at work we do not, ever, login to our laptops and desktops with a domain admin account or an account with extra administrative permissions over server systems.

 

5 hours ago, LAwLz said:

You seem to be defending yourself against a type of attacker I don't even think exists. An attacker that is good enough to brute-force a good password (which will take hundreds if not thousands of years, even with a script) but not knowledgeable enough to look up the username of the account they are attacking.

Or one where the logged in user is being exploited without their knowledge, because that is more common than anything else.

 

The other common one you missed is the nuisance users locking the account out because they have nothing better to do, like doing their school work. You can lock out local accounts.

 

5 hours ago, LAwLz said:

If the attacker does have a login, then they can just look up the database and see the account names.

Basically the entire Audit Failure logs I see when there has been a password attack is on common user names, checking for admin group accounts is rarely done, like administrator and root. Why you would be trying the username root on Windows I don't know but like I mentioned not all attackers are actually that smart or even made the tool they are using.

 

Plenty of attacks come from compromised computers doing remote attacks, that's why BYOD can be bad. BYOM (Bring your own Malware) can be an accurate alternative name.

[Guest]

6 minutes ago, leadeater said:

Correct though we are talking more about the security model not the functionality of the account itself, not using a well known account and not running with admin prviledges all the time.

 

To that similar extent at work we do not, ever, login to our laptops and desktops with a domain admin account or an account with extra administrative permissions over server systems.

Linux systems could be completely unexposed to brute force attacks on the network via SSH using certificates and disabling account access, well as for physical access I already said that tl;dr a couple of posts before, ubuntu tries just to simply that thing by disabling the root access via displaymanager/tty
Names are readable by everyone btw as /etc/passwd doesn't have protection for every user 

Well you could discuss a lot on this, even if windows is a completely other world, and anyway as long as you have physical access to a machine unless you are physically and constantly watching users there is no 100% layer of security 

[leadeater]

14 minutes ago, Lukyp said:

Linux systems could be completely unexposed to brute force attacks on the network via SSH using certificates and disabling account access

Though not a default thing, we do actually do that though. But either way I think the point is lost on a lot of people or just have not for some reason encountered it but attacks on common account names are not uncommon, usually not at all sophisticated so just not using those is a really simple thing to do. Arguing against it is in my view entirely pointless because the account in question is now disabled by default and there is a zero effort difference between either enabling it or creating your own.

 

In light of actually encountering many such password attacks that only use these well known account names I would always advise to not use them.

 

Edit:

Or maybe because I've historically been a contractor/consultant so get exposed to many different networks rather than be employed and work on a single one. Or it could be that the education sector is just at more risk than others. Either way for me password attacks are not uncommon so identifying what is common about them and mitigating those is a smart thing to do.

[Guest]

48 minutes ago, leadeater said:

Though not a default thing, we do actually do that though. But either way I think the point is lost on a lot of people or just have not for some reason encountered it but attacks on common account names are not uncommon, usually not at all sophisticated so just not using those is a really simple thing to do. Arguing against it is in my view entirely pointless because the account in question is now disabled by default and there is a zero effort difference between either enabling it or creating your own.

 

In light of actually encountering many such password attacks that only use these well known account names I would always advise to not use them.

There is also the thing where if you don't know at least one account + password even without administrator access, you can't get the account list (c:\Users for example)

Same applies on Linux 

 

I don't know if there is way to automatize the brute forcing on display managers in Linux or the login screen on Windows other that smashing the physical keyboard in this case?

 

As for getting the password hashes they can be accessed only from Administrator user and users from the administrator group right? 

 

So leaving the administrator account disabled only helps in this case if you got some thief that doesn't know nothing right next to your company PC trying all the password and user combinations possible with a keyboard and this dude don't even know the user list

[samcool55]

4 hours ago, Sauron said:

I think the comparison between root and Administrator breaks down here... root actively does things in Linux that are necessary for the system to work. Privileged services and much more are run as root, even if you have a "sudoer" account. Furthermore, whenever you do something as superuser in Linux, you're actually asking root to do it, whereas in Windows the Administrator account isn't called every time you click "run as administrator" (at least as far as I know - otherwise disabling the account would break that functionality).

When you press that "run as administrator" button you do request A administrator account to take over, not the default one, any admin account will do. But the default one can be used if you want.

 

The reason why it's not that broken as it might seems like is because there is almost always a different account that has admin rights.

 

Because windows has UAC it's a bit more complicated. Everytime you get one of those UAC pop-ups it's because something requires elevated rights. By default a standard user has permission to give authorization to some of those rights that can be requested, but not all of them. That's why you can press "yes" or "ok" or whatever as a standard user in some UAC promps while the program happily continues. But that's not the case for everything. For some things you need permissions that can by default only be given by a default admin. (the reason why i say by default everywhere is because you can technically take a standard user and allow it to do everything making it basically an admin.)

 

I'm not a master when it comes down to user rights and access on Linux, but with Windows it's very visible what's actually going on rights/permission wise.

 

If you would remove your administrator account and leave the default disabled, you don't have many options left to fix that. (also windows usually doesn't allow you to remove an admin account when it's the only one left enabled) but it's not impossible. Profiles can go corrupt and when the profile of your only admin breaks, you have a big problem.

 

Back when we didn't have bitlocker or online accounts we would just modify the OS with a new admin user but that's not really a thing anymore...

 

What windows does to compare it to linux is it creates a root user, but disables it and let you create another root account (with the same permissions) that you can use if you need root to do stuff.

 

[leadeater]

4 hours ago, Lukyp said:

So leaving the administrator account disabled only helps in this case if you got some thief that doesn't know nothing right next to your company PC trying all the password and user combinations possible with a keyboard and this dude don't even know the user list

Most password/account attacks are just hit and run from compromised devices or over the internet to exposed services like web login forms or RDP servers. Most attacked tend to be RDP.

 

A lot of people have SMB enabled so they can copy files across computers, you can just direct an attack through that trying to connect to C$ or admin$. Either way you just need some entry point in to the system that will prompt for authentication and you're good to go attack wise.

 

Most bot nets just do password attacks as it is along with port scans, find an open port, detect service type, spam authentications until it works or port no longer responds.

[YaBoiWill]

I only used the account for managing permissions and file shares, it has a stupidly long password, about 20 characters I think, so its pretty secure compared to my own account 

[Guest]

57 minutes ago, leadeater said:

Most password/account attacks are just hit and run from compromised devices or over the internet to exposed services like web login forms or RDP servers. Most attacked tend to be RDP.

 

A lot of people have SMB enabled so they can copy files across computers, you can just direct an attack through that trying to connect to C$ or admin$. Either way you just need some entry point in to the system that will prompt for authentication and you're good to go attack wise.

 

 

rofl who enables more than one user especially administrator on SMB X*3

Anyway I know, my friend server got attacked by some random script which changed his root password via ssh (he was using a very stupid one, he was just running  a ssh server + minecraft on his old potato pc) 

Would be easy to do that on python

[duncannah]

Didn't know you could enable an actual admin account, if only I knew that when I tried mounting an NTFS drive from another installation >_>

If they fixed all them permission issues then there wouldn't be an use for the account

[ZacoAttaco]

They should probably just start over with this update at this point, there is clearly something fundamentally wrong with an update that causes this many issues.

[LAwLz]

6 hours ago, leadeater said:

Basically the entire Audit Failure logs I see when there has been a password attack is on common user names, checking for admin group accounts is rarely done, like administrator and root. Why you would be trying the username root on Windows I don't know but like I mentioned not all attackers are actually that smart or even made the tool they are using.

 

Plenty of attacks come from compromised computers doing remote attacks, that's why BYOD can be bad. BYOM (Bring your own Malware) can be an accurate alternative name.

It's simple.

Usernames are not meant to be secret, and they are not designed to offer protection. Don't use it as a security feature because they aren't. It's super easy to look up exactly which accounts has administration rights.

If you see some unsophisticated attack written by someone who can't even figure out how to look up which account name to attack, then you don't have to worry about the attack because your password should be strong enough to withstand that attack.

 

You're defending yourself against this super weird, primitive attack that just tries to brute force the account Administrator, while simultaneously being advanced enough to use either some type of password bypassing exploit, or a massive amount of computational resources to brute force strong passwords. It makes no sense.

 

It's simple.

Either the attack is primitive, in which case it won't get by a strong password anyway.

Or the attack is more sophisticated, in which case it will be able to sniff out the other account names and target those.

 

Feel free to keep creating other accounts with administrator privileges if you want, but if you ask me it's a waste of time.

[leadeater]

27 minutes ago, LAwLz said:

Usernames are not meant to be secret, and they are not designed to offer protection. Don't use it as a security feature because they aren't. It's super easy to look up exactly which accounts has administration rights.

If you see some unsophisticated attack written by someone who can't even figure out how to look up which account name to attack, then you don't have to worry about the attack because your password should be strong enough to withstand that attack.

And how does an attacker doing a password attack on say an RDP port look up user account lists?

 

Simply no, there is a reason to not use built-in administrator account. It's painfully obvious, every knows about it and will try and crack it. It's not supposed to be some ultimate defense it's just a logical step that should be taken in securing your networking, one of many. And I'd rather not have to deal with account lockouts when it happens. I don't care if it's never going to be cracked, I don't want legitimate administrator accounts being hit with failing authentication request locking it out or filling up logs. Clean logs are easier logs to analyse and will hold more valid information for longer without having to access archives etc.

 

You know what is more stupid, re-enabling the administrator account rather than taking Microsoft's advice and every other security firm and auditor who say to leave it disabled and not create your own at no extra effort.

 

You literally have 2 choices, enable built-in administrator or create a different one. Both are manual, both require someone to do something, do the thing that is best practice that almost everyone recommends. And I say almost because until now I've never meet someone who would choose to enable the administrator account after being told why it is best not to.

[leadeater]

2 hours ago, Lukyp said:

rofl who enables more than one user especially administrator on SMB X*3

It doesn't matter what you do, the mere fact you can put authentication request towards it is the issue. You get different response codes based on what happened. Being denied due to incorrect password is a different code to a successful authentication but not having the required permission to access the share.

 

And as far as multiple users, of course, what if it's a share used by say an entire department.

 

Any system that is open to authentication requests in any way is also open to being attacked, that's just pure nature of the game.

 

Your all welcome to re-enable built-in administrator if you want, I never will because under a Windows environment it's best not to. There isn't a single good reason to other than I have always used it and I will continue to, which isn't a good reason.

[Guest]

8 minutes ago, leadeater said:

It doesn't matter what you do, the mere fact you can put authentication request towards it is the issue. You get different response codes based on what happened. Being denied due to incorrect password is a different code to a successful authentication but not having the required permission to access the share.

 

Your all welcome to re-enable built-in administrator if you want, I never will because under a Windows environment it's best not to. There isn't a single good reason to other than I have always used it and I will continue to, which isn't a good reason.

Isn't that a SMB fault? 

 

Anyway I'm sure you could strict access for any local account user including administrator even if enabled on SMB, at least the Windows implementation as I do that also on samba in Linux 

 

I'm just curious anyway, I use Windows only when I have to play games lol I don't even touch a single thing because I have bad experience in breaking it for no reason 

[leadeater]

1 minute ago, Lukyp said:

Isn't that a SMB fault? 

Yea, though you wouldn't expose SMB to the internet, that would legit be rather insane. RDP is common though as most places want remote access. I restrict RDP connection attempts to trusted geolocations now just to keep the noise down. Even if you use different non default port for RDP it gets found eventually and then sure enough username/password attacks come in.

 

4 minutes ago, Lukyp said:

Anyway I'm sure you could strict access for any local account user including administrator even if enabled on SMB, at least the Windows implementation as I do that also on samba in Linux 

You can but that's not actually the problem. C$ and admin$ are default restricted to administrators but you still have to authenticate against the computer and it still has to check the provided username/password and then respond back. As I mentioned there is a different return code for each different outcome, security wise it would be better to only have one failure message however there are more legitimate troubleshooting/debugging reasons why you'd actually want a different error message for different failure/denied reasons.

[yian88]

12 hours ago, Lukyp said:

Uhh honestly I developed myself a couple of Unity project and the IDE wasn't that bugged, I once run UE4 too, and I didn't find a single issue, except the usual ones that also happen on Windows 

An alternative to Proton is Lutris, depending on the script it could even include the Proton own wine version with all the fixes in there also for non-steam games

I think some time in the future wine could gain more importance instead of native linux ports, I mean, currently DXVK in 1 year has done more than developers releasing poor linux ports in a decade especially from a performance standpoint the difference in frame per seconds is very little, and it is just an alpha

10 years ago if you said "in the future you could run DX11 games on linux this easily and with a little performance drop" they would treat you like crazy, you can't tell what's going on in the future

Wine also includes compatibility for other programs than games like the adobe suite for example, and huuh just saying maybe in the future the compatibility would be almost perfect, definitely a thing to increase market share and hope for more native ports (or even if windows apps would be running perfectly fine and seamless)
 
The anticheat engines for wine are the big issue currently as EAC for example uses a Windows driver, and there is no translation currently in Wine for Windows drivers.

Idk i never managed to run anything in Wine or playonlinux, only managed to run 1 game with proton forgot which one, i also tried monster hunter world doesnt work so i gave it up.

[LAwLz]

7 hours ago, leadeater said:

You literally have 2 choices, enable built-in administrator or create a different one. Both are manual, both require someone to do something, do the thing that is best practice that almost everyone recommends. And I say almost because until now I've never meet someone who would choose to enable the administrator account after being told why it is best not to.

Got a link to where it says it's best practice to keep it disabled? All I know is that they used to recommend disabling the automatically generated Administrator account in the domain, but they now recommend keeping it enabled because it is the only account that works in certain disaster recovery scenarios.

 

Anyway, like I said earlier I don't see how it provides any meaningful protection. Like I said earlier, it's like painting your nuclear shelter with three layers of paint, saying it provides better protection than 2 layers. It's technically true, but superfluous.

 

7 hours ago, leadeater said:

Yea, though you wouldn't expose SMB to the internet, that would legit be rather insane. RDP is common though as most places want remote access. I restrict RDP connection attempts to trusted geolocations now just to keep the noise down. Even if you use different non default port for RDP it gets found eventually and then sure enough username/password attacks come in.

If I were you, I'd not allow any RDP from the Internet inside my network. Make people connect with VPN if they want to access RDP instead. Having RDP exposed to the world is in general a pretty bad idea from a security standpoint. But I guess that depends on how peoples' workflow looks.