Samba Problem Lets Any User Change Admin Passwords

rgMekanic

[H]ard|News
Joined
May 13, 2013
Messages
6,943
The Register is reporting that "On a Samba 4 Active Directory domain controller (AD DC) any authenticated user can change other users' passwords over LDAP, including the passwords of administrative users and service accounts." The problem is in all versions of Samba from 4.0.0 and newer where it incorrectly validates permissions to change any other users' passwords over LDAP.

Pretty big bug that has been going on for a while from what it sounds like. You can read the full advisory warning from Samba here, and then get to patching.

There’s some good news in the form of this simple workaround samba_CVE-2018-1057_helper --lock-pwchange that turns off the mistakenly loose password-setting permissions. Once you’ve done that, visit samba.org/samba/security/ to download patched Samba versions 4.7.6, 4.6.14 and 4.5.16 to fix recent releases.
 
samba is known for file sharing between windows and other systems.
Samba active directory controller? Never heard of such an animal.
 
samba is known for file sharing between windows and other systems.
Samba active directory controller? Never heard of such an animal.

Likewise. I've only ever used it to share between my Windows servers and Linux servers.
 
Its not too different than how Windows clients run most all of the basic services that support AD Domain Controllers. You can even run Lightweight Directory Services on Windows 10. The only AD Directory Services components MS effectively charges for are the Kerberos server and Group Policy server components (DS allows connections from the good tools whereas LDS is often more basic). ...and CALs :D

Samba server just emulates those parts in addition to SMB/CIFS
 
This is why I want a good NFS client for Windows versions other than Enterprise. Can't seem to find any.
 
wow I didn't realise Samba was so far along in emulating windows network share stack
 
samba is known for file sharing between windows and other systems.
Samba active directory controller? Never heard of such an animal.

It is used by Linux zealots. You get some IT people who get reeeeeealy zealous about their platform and get this "Windows can't be a server EVAR" attitude. But they work for a company that needs Windows on the desktop. So they use Samaba as a DC... It generally doesn't work out so great.
 
Hopefully Synology is patching this soon. Not sure that I want to manually patch it, since I'm quite new to the NAS.

As for NFS, it appears it's now available on Windows 10 pro (though sounds like it still has issues).
From https://serverfault.com/questions/821316/why-doesnt-the-nfs-client-work-in-windows-10-pro

So with your latest windows 10 PRO 14393.576, your NFS's client is finally operational in comparison with before like shown in this thread: as stated before by Tom jolly Tom Jolly (Group Software Engineering Manager) in the same thread, they were working on a fix because of problems with the transition from Windows Ultimate and Windows Enterprise 7 to Windows 10 PRO. It has been released in the last update.

Don't forget to install the nfs client from Windows features (will show some images later). To mount the share you can do it through Explorer like you would do with samba share so


\\x.x.x.x\share


or you can do it through command line with mount


x.x.x.x:/share or \\x.x.x.x\share drive:


Some things you should know.


  • User permission won't really work out of the box like to would be in Linux. So it is very probable that Explorer accept to map the share but won't accept to enter the share. So begin to set up a share where everybody will be able to write and read. So with chmod -R 777. I guess that the nfs client is not totally implemented.
  • Software like acronis true won't be able to enter the share either because it seems that a whole extended interfaces features have been added to Explorer so guess is that software have to be coded to implement those yet.
  • Don't be afraid of the big latency that Explorer seems to have in comparison of Linux, again the implementation is not yet perfect.
  • if you map through command line to a drive letter, the mapping won't survive a reboot.


    If anyone else have some new knowledge based on experience or reading about others bugs and possible problems with this NFS's client, please do share.

 
Its only an issue if you use Samba as a domain controller. If you are just using it as a file server this is not an issue.

NFS on windows could become a think with NFS4 supporting ACLs now. Biggest issue with NFS on windows is that the permission style is VERY different. Yes I know Linux file systems support ACLs now but from what I've seen they are far from commonly implemented.
 
It is used by Linux zealots. You get some IT people who get reeeeeealy zealous about their platform and get this "Windows can't be a server EVAR" attitude. But they work for a company that needs Windows on the desktop. So they use Samaba as a DC... It generally doesn't work out so great.
I always thought active directory was a windows environment thing. Running active directory on linux is ... surprising to me. But i mean whatever floats your boat i guess....
 
I always thought active directory was a windows environment thing. Running active directory on linux is ... surprising to me. But i mean whatever floats your boat i guess....

Usually it is. Normally you'd run an AD back end because you are a Windows shop, and then maybe use Samba to authenticate to that if you have some Linux systems mixed in (there are other methods too for mixed auth). But like I said, you get zealots in tech. I've known a few that have the view that Windows cannot be the backend server for anything, EVAR and thus will go to silly lengths to try and make everything on the backend Linux.

I've never gotten it personally, at work we are a mixed environment and we use Linux for the Linux stuffs, Windows for the Windows stuffs and all is well. But some people get real hardcore about it.
 
It can just as easily be used by competent Linux Administrators too. I myself have personally implemented Samba AD DCs, redundantly, in production, and it was far more reliable than the Windows Server 2003 it replaced. Reboot times inside 30 seconds, 512MB of RAM usage, and all the tasty AD-centric features retained that I cared about. GPOs, AD OU/User structured, etc.

I think you should revisit the robustness of Samba running AD DCs. Sure, it isn't feature parity with Windows Server 2016, but there are plenty of good reasons to use it. Firstly, no license constraints (CALs/DALs/etc).

It is used by Linux zealots. You get some IT people who get reeeeeealy zealous about their platform and get this "Windows can't be a server EVAR" attitude. But they work for a company that needs Windows on the desktop. So they use Samaba as a DC... It generally doesn't work out so great.
 
NFS has been available for Windows for quite a long time now. However, Microsoft has not cared enough to make the NFS mechanisms actually fast and reliable.

Now, I can't speak about a recent Windows 10 implementation of it, but server editions of Windows that have NFS client support include (but may not be limited to) 2008(R2) and 2012(R2). However they, by default, use UDP out of the box, and as such it operates quite poorly. Registry editing to switch it to TCP can improve it, but it's still kinda meh from what I've heard.

Hopefully Synology is patching this soon. Not sure that I want to manually patch it, since I'm quite new to the NAS.

As for NFS, it appears it's now available on Windows 10 pro (though sounds like it still has issues).
From https://serverfault.com/questions/821316/why-doesnt-the-nfs-client-work-in-windows-10-pro

So with your latest windows 10 PRO 14393.576, your NFS's client is finally operational in comparison with before like shown in this thread: as stated before by Tom jolly Tom Jolly (Group Software Engineering Manager) in the same thread, they were working on a fix because of problems with the transition from Windows Ultimate and Windows Enterprise 7 to Windows 10 PRO. It has been released in the last update.

Don't forget to install the nfs client from Windows features (will show some images later). To mount the share you can do it through Explorer like you would do with samba share so


\\x.x.x.x\share


or you can do it through command line with mount


x.x.x.x:/share or \\x.x.x.x\share drive:


Some things you should know.


  • User permission won't really work out of the box like to would be in Linux. So it is very probable that Explorer accept to map the share but won't accept to enter the share. So begin to set up a share where everybody will be able to write and read. So with chmod -R 777. I guess that the nfs client is not totally implemented.
  • Software like acronis true won't be able to enter the share either because it seems that a whole extended interfaces features have been added to Explorer so guess is that software have to be coded to implement those yet.
  • Don't be afraid of the big latency that Explorer seems to have in comparison of Linux, again the implementation is not yet perfect.
  • if you map through command line to a drive letter, the mapping won't survive a reboot.


    If anyone else have some new knowledge based on experience or reading about others bugs and possible problems with this NFS's client, please do share.
 
Microsoft Active Directory is a technology developed by Microsoft (surprise!). It initially was rolled out for Windows Server 2003 (before that were NT workgroups or other methods).

A whole bunch of years ago (I forget exactly when this went down), there was an anti-trust case that was completed against Microsoft's Active Directory. As such, the source code has been made available to certain developers in the Samba project. As such, the software developers that have been, and are, developing Samba 4 AD, literally read the Microsoft Active Directory source code. Naturally, they also are covered by hefty NDAs.

How do I know? Well... I've talked with them, and I provide professional support and implementation services for Samba in many forms.

I always thought active directory was a windows environment thing. Running active directory on linux is ... surprising to me. But i mean whatever floats your boat i guess....
 
It can just as easily be used by competent Linux Administrators too. I myself have personally implemented Samba AD DCs, redundantly, in production, and it was far more reliable than the Windows Server 2003 it replaced. Reboot times inside 30 seconds, 512MB of RAM usage, and all the tasty AD-centric features retained that I cared about. GPOs, AD OU/User structured, etc.

I think you should revisit the robustness of Samba running AD DCs. Sure, it isn't feature parity with Windows Server 2016, but there are plenty of good reasons to use it. Firstly, no license constraints (CALs/DALs/etc).

I'm assuming you're talking about Samba 4.0+ right? You could do "domain" ish functions on older versions, but AFAIK those didn't support GPOs, and from previous experience it was a bit of a hack job to just try to get a Windows pc to join a Samba domain as it would throw an error and you had to do some workaround to get it to join properly. The other thing I'm wondering is if you have TLS 1.2 actually up and working or not. LDAP does not like to play nicely between systems because of differences in supported ciphers / number of ciphers you can use at once.



EDIT: To address the original topic, this might not blow up because no one is using this functionality, but this seems like a huge oversight on someone's part to miss something like this. Given it affects ALL versions made in the last 5 years that definitely wouldn't be giving me a warm and fuzzy feeling about wanting to implement something which could be completely compromised by any user account in your domain. Did someone already find this years ago and just not tell anyone? Obviously changing the password of user account should tip some people off because you can't just set it back, but if you had an account sitting out there no one was really paying attention to, that could have been used to do things and you might never notice.
 
Last edited:
I always thought active directory was a windows environment thing. Running active directory on linux is ... surprising to me. But i mean whatever floats your boat i guess....

Unfortunately some apps ‘require’ active directory for auth. Federation can drive you to it as well.

More enlightened ones use Kerberos and generic LDAP, for example, as a replacement for that functionality in AD. If you go MS native the amount you’d pay in server licences, and CALs just for that is insane. Even AzureAD (or aws equiv) is horrifically expensive so people do use this. (Me, I’d just dump the app)

Thankfully this problem is becoming less prevalent as things become web apps and SAML / oAuth support ihas become much more common in the last few years.
 
I'm not sure about the anti-trust part, but you're incorrect as to the introduction of Active Directory. It was introduced in Windows 2000 Server.


Microsoft Active Directory is a technology developed by Microsoft (surprise!). It initially was rolled out for Windows Server 2003 (before that were NT workgroups or other methods).

A whole bunch of years ago (I forget exactly when this went down), there was an anti-trust case that was completed against Microsoft's Active Directory. As such, the source code has been made available to certain developers in the Samba project. As such, the software developers that have been, and are, developing Samba 4 AD, literally read the Microsoft Active Directory source code. Naturally, they also are covered by hefty NDAs.

How do I know? Well... I've talked with them, and I provide professional support and implementation services for Samba in many forms.
 
Ahh, I thought Win 2000 were still using NT domains, not AD. Honestly, 2000 was before I started working with AD.

I'm not sure about the anti-trust part, but you're incorrect as to the introduction of Active Directory. It was introduced in Windows 2000 Server.
 
I think you missed the part where I was careful to use the terms "AD DC" as in ActiveDirectory Domain Controller(s).

Pre Samba 4.0 the "domain" functionality was NT Domains, not AD Domains. This is why I used the AD DC nomenclature.

I implemented Samba 4.0 AD DCs to production, but only after _MONTHS_ of testing, peer review and research. I did not see Windows desktops or servers have issues joining the domain, when it was correctly implemented.

It is however worth noting that about the same time, you could get the Samba package from many different sources. Different repos, and stuff like that. Some of them did not build Samba correctly, and this actually lead to a lot of false issues. As in, silly reasons would come up why X functionality wouldn't work. This happened to me early in my research on it (READ: BEFORE DEPLOYMENT), and happened to plenty of other people. One of the "solutions" was to use a repositor (SerNet) that built the packages in a reliable way. Seriously, this cleared up all obscure issues that came up. Perhaps this was what was happening in the examples you've heard of. Because honestly, it was not easy to find out that how it was built was a source of a lot of problems.

Since then the package has been built far more reliably by main repos, but I do keep this facet in the back of my mind still.


I'm assuming you're talking about Samba 4.0+ right? You could do "domain" ish functions on older versions, but AFAIK those didn't support GPOs, and from previous experience it was a bit of a hack job to just try to get a Windows pc to join a Samba domain as it would throw an error and you had to do some workaround to get it to join properly. The other thing I'm wondering is if you have TLS 1.2 actually up and working or not. LDAP does not like to play nicely between systems because of differences in supported ciphers / number of ciphers you can use at once.



EDIT: To address the original topic, this might not blow up because no one is using this functionality, but this seems like a huge oversight on someone's part to miss something like this. Given it affects ALL versions made in the last 5 years that definitely wouldn't be giving me a warm and fuzzy feeling about wanting to implement something which could be completely compromised by any user account in your domain. Did someone already find this years ago and just not tell anyone? Obviously changing the password of user account should tip some people off because you can't just set it back, but if you had an account sitting out there no one was really paying attention to, that could have been used to do things and you might never notice.
 
Pre Samba 4.0 the "domain" functionality was NT Domains, not AD Domains. This is why I used the AD DC nomenclature.

No I didn't miss it, but this answers the question. You're specifically talking about 4.x+ having true AD functionality, where previously to that they did not. (Confirming what I thought) I came across a system that was built on Samba 2.x a long time ago and about the only thing it did for you was give you a common way to authenticate a user as far as I remembered. I've never built a system on Samba 4.x, so it's basically a non issue for me. It's cool that it's there, but it certainly would be a tough sell to most people I think. Yes you're not paying the MS tax, but then you're also paying for a Linux admin who specializes in software that few use. You can throw a dart in any direction and hit someone who knows how to use AD, Samba is going to be another story. Same goes for finding a vendor to help you with issues you can't solve, and every time you need to do an integration the partner is going to look at you funny any blame every issue you have against the fact that it's not MS software. Not saying that it's going to be Samba's fault or that it won't work, but there will be tradeoffs when going down that route.


I am curious though, have any of your customers done an Azure AD integration with a Samba domain? I'd guess it would be extremely rare if you were in the non MS camp you'd want AAD in the first place, but it does offer functionality that some customers might want. (SSPR, SSO, Office 365, etc)
 
Back
Top