Web lists-archives.com

Re: [Samba] External Authentication




Hi Vex,

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...

Peter


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@xxxxxxxxxxxxxxx> wrote:

On Thu, 11 Apr 2019 10:54:13 -0700
Vex Mage via samba <samba@xxxxxxxxxxxxxxx> 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
directive.
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 this
network except for Samba. We're being held back because of the Samba.



https://wiki.samba.org/index.php/Migrating_a_Samba_NT4_Domain_to_Samba_AD_(Classic_Upgrade)

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 centralized
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 quite 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.



Rowland



--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba





--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba