[Samba] External Authentication
miles at atmos.eu
Fri Apr 12 08:54:02 UTC 2019
There's always the alternative to install a Microsoft server, and pay
for everything. For an educational institution, the license fees are
acceptable, but the MS licensing conditions are very complex. In
principle you need a license for every device that connects to a MS
server, plus the OS license(s). And the hardware. Another alternative is
Redhat IPA (and clones). And corporate systems for zillions of users
(but that isn't the case here, I guess).
If the domain is a large one, the migration from a Samba NT domain to a
Microsoft AD domain will probably not be easier, than migration to a
Samba AD domain. And the complexity of domain administration are
comparable. So there's really nothing to gain using true MS stuff.
Unless you have got very specific requirements that cannot be met by Samba.
I did the migration to a Samba AD domain half a year ago, and it works
very well. Administration is a snap, compared to the NT domain
administration. Continuing to use the Samba NT domain was just not
feasible anymore. Ransomware and other malware propagating through NT1
shares were arguments enough to make me switch. And antivirus systems
are not perfect.
I'm convinced that you will realize that the choices are quite limited.
Naturally, it's frustrating. Paramount are security, compatibility, and
future proofing, as well as low resource requirements. In my case, using
a Samba AD DC was the natural choice.
Just my five cents...
On 11.04.2019 23:37, Vex Mage via samba wrote:
> On Thu, Apr 11, 2019 at 11:32 AM Rowland Penny via samba <
> samba at lists.samba.org> wrote:
>> On Thu, 11 Apr 2019 10:54:13 -0700
>> Vex Mage via samba <samba at lists.samba.org> wrote:
>>> Hello, I've done a lot of reading and searching however; I could use
>>> some guidance. I just started working for a school in which there are
>>> a few Windows labs as a Linux systems administrator. Our workstation
>>> sysadmins have asked me to look into a Samba issue for them, Windows
>>> 10 systems have to have SMB1 turned on to authenticate against the
>>> existing Samba3 server. This work around hasn't been acceptable due
>>> to privacy and security concerns. The campus has a black box LDAP
>>> server for which we use to authenticate users. The Samba3 server is
>>> currently using this LDAP to authenticate users.
>> That is your problem right there, Samba 3 is EOL, dead, finito
> Correct, that's why I'm on the case. My predecessors stopped updating it
> due to compatibility issues. I'm just trying to find a way forward.
>>> I've spun up a Samba4 server and set it up as an active directory
>>> domain controller and I can definitely see that this is a very robust
>>> system and is working well however; I don't see a management solution
>>> to synchronization between the campus LDAP server and Samba4 AD/DC.
>> There isn't one, AD is supposed to replace your NT4 domain
> Yea, I believe that is the point of what I'm trying to do.
>>> One approach I was thinking was leveraging "password server" and
>>> point the directive to the Samba3 NT4 domain and turn on the auto
>>> creation of accounts. Groups would still need to be managed by hand.
>>> The issue is that the Samba4 server seems to not be honouring the
>>> password server directive. Indeed I cannot find any directed traffic
>>> from Samba4 to Samba3 during an authentication attempt with the
>> See the answer above, plus there is a very big hole in your proposed
>> set up, if your clients see the AD DC, they will not contact the NT4
>> PDC again.
> I'm just trying to find a way to make Samba4 be useful in some way and so
> far I can find no place for it, let alone any use of it.
>>> I can also think of a convoluted LDAP diff of both systems to shore
>>> up the Samba4 LDAP with the campus LDAP however; this script would
>>> have to run periodically and I'm currently not aware whether Samba4
>>> can read the blackbox LDAP password encryption type.
>> I have heard of some convoluted ways of doing things, but yours just
>> might be the strangest ;-)
> Thanks, if Samba worked like it used to perhaps one wouldn't have to think
> so far out of the box and we could just get things done?
>>> I'm looking for the most straightforward way for Windows desktop
>>> authentication of users and groups. I cannot seem to be all in for
>>> Samba4's AD and I can't seem to be all in for campus LDAP (by way of
>>> Samba3's NT4 LDAP back end).
>> First and foremost, you need to turn off your Samba 3 machine (yes, I
>> know you wont like this), it is insecure. You will be better off
>> classicupgrading your PDC to an AD domain, see here:
> No, I really have no problem with that. It would be perfectly fine to
> upgrade if Samba4 was as flexible as Samba3. There's nothing legacy in
> network except for Samba. We're being held back because of the Samba.
> The problem is that there is no apparent upgrade path for the old system.
> The corner stone of this deployment is that there's an existing
> authentication server however; Samba4 seems wants a paradigm shift so that
> it becomes the princess of its own castle. It seems to me that it has
> become the very thing that birthed its creation, a monster that wants to
> strand its user base into its own proprietary system. All I trying to
> do is
> to make Windows play nice with an existing open source authentication
> server but all I'm hearing from the Samba project are vain, and to be
> frank very condescending tones about switching all authentication to
> its AD
> server. In my opinion the Samba project has devolved since I've last
> had to
> work with it and it has become inflexible and passé. I do not think that
> there will be a place for Samba if Microsoft continues to extend it's
> offering to open source community. I didn't want to believe my compatriots
> about the Samba4 issue. I feel like the terrorists have already won.
> I really do appreciate that you took your time to reply but everything you
> have said has been vapid, the mantra of a dead rhetoric. Thank you for at
> least trying. Have a great day.
>> To unsubscribe from this list go to the following URL and read the
>> instructions: https://lists.samba.org/mailman/options/samba
More information about the samba