[Samba] Samba4 + FreeIPA

Patrick Goetz pgoetz at math.utexas.edu
Fri Nov 5 11:51:10 UTC 2021



On 11/5/21 06:28, Rowland Penny via samba wrote:
> On Fri, 2021-11-05 at 05:57 -0500, Patrick Goetz via samba wrote:
>>
>> On 11/5/21 02:52, Rowland Penny via samba wrote:
>>> On Thu, 2021-11-04 at 19:15 -0400, Robert Marcano via samba wrote:
>>>> On Thu, Nov 4, 2021, 3:37 PM David Mulder via samba <
>>>> samba at lists.samba.org>
>>>> wrote:
>>>>
>>>>> On 11/3/21 7:45 AM, Cyrus via samba wrote:
>>>>>> Thanks a lot. For this environment we have a 20/80
>>>>>> distribution,
>>>>>> being
>>>>> 80%
>>>>>> Linux servers, workstations & kiosks.
>>>>>>
>>>>>> Windows is indeed limited to some limited administrative user
>>>>>> group
>>>>> (higher
>>>>>> management & accounting department).
>>>>>>
>>>>>> I'm find with the dual realm, with all the users on one side
>>>>>> &
>>>>>> trust
>>>>>> between both parties.
>>>>>>
>>>>>> Probably it makes sense to go dual setup in this case.
>>>>>> Sudoers &
>>>>>> HBAC
>>>>> feel
>>>>>> more convenient with FreeIPAs WGUI/CLI.
>>>>>
>>>>> Samba sudoers and hbac are deployed via either `samba-tool gpo`
>>>>> command
>>>>> or Windows RSAT. It's no less convenient than the FreeIPA
>>>>> tools.
>>>>>
>>>>
>>>> There is a reason I mentioned that this depends on the
>>>> relationship
>>>> between
>>>> how many Linux (in reality 'unixy' OSs) vs Windows you have. If
>>>> you
>>>> are
>>>> mainly a Linux shop with a few Windows, the need to use a Windows
>>>> client
>>>> for some management functions is definitely an inconvenience.
>>>> Nothing
>>>> more
>>>> convenient that a browser GUI.
>>>>
>>>> Don't get me wrong, I understand that reason for the lack of open
>>>> GUIs to
>>>> manage Samba AD is a community issue, mainly contributions. Ah!
>>>> And
>>>> having
>>>> to reverse engineer MS protocols and file formats.
>>>
>>> It may just be myself, but I cannot really see the point of using
>>> freeipa. Everything it can do, Samba can do, but you cannot say the
>>> same in reverse, Samba can do more than freeipa.
>>>
>>
>> A hard truth:
>>
>> I've followed open source projects for decades. The one single thing
>> that determines whether or not an open source project will be
>> successful?  Good, reasonably comprehensive documentation.  You can
>> have
>> the most elegant, functional code ever written, and no one will use
>> it
>> if it's not documented properly.  Look at how long it's taken for
>> nftables to gain *any* market penetration. No one would still be
>> using
>> it if people hadn't starting writing transparent iptables to
>> nftables
>> backend translators. Why? Because the people working on that code
>> base
>> refuse to document it properly. Documentation isn't their thing. Why
>> has
>> the Django project been so successful? Because it was written by
>> media
>> people, so one of the first things they did was write clear and
>> comprehensive documentation. Terrible code, but great documentation.
>>
>> Currently, the Samba project is hurt by a lack of good
>> documentation.
>> Samba 3 documentation was really good, but that effort wasn't
>> repeated
>> for v. 4 for some reason. There are no current books available, and
>> the
>> Wiki is littered with lacunas and inaccuracies like the one that
>> threw
>> me off in my previous post today. Time wasted because I labored
>> under
>> the assumption I was getting correct information from the Wiki.
>> That's
>> all there is to it. It's extremely frustrating to potential users,
>> so
>> people start to look for alternatives. If you already know something,
>> it
>> can be hard to distinguish between hard and easy; confusing and
>> obvious.
>> That's you: you know Samba, so can't fathom why everyone else
>> doesn't
>> use it - it's obviously the superior solution. But me, as someone who
>> is
>> for all practical purposes a modern Samba novice, I probably would
>> have
>> given up long ago save for all the help I get from yourself and this
>> list. And that's coming from a very experienced admin who has used
>> Samba
>> in the past. Not everyone has time to camp out on a listserv,
>> though;
>> they want to read a book or some well organized online resources
>> implement, and move on to the next thing.  So many IT projects, so
>> little time ...
>>
>> This is a shame, because it's a great project; the more I use
>> 4.15.x,
>> the better I like it and the more impressed I am by how it works.
>> But
>> yeah, you asked, so I'm explaining what the issue is. I see many
>> complaints on Stack Exchange and elsewhere about the state of Samba
>> documentation. I recall one recent response to a question "yeah, you
>> could try to use Samba, but the documentation is a mess". And then
>> the
>> OP is directed to try FreeIPA.
>>
>> This is why I suggested you write a book in a post you probably
>> didn't
>> read. <:)
> 
> Oh, I did read it, but I ignored it, I do not have the temperament to
> write a book and at my age, I do not think I will change.
> 
> Yes, the wiki could be better, but then it is written from the point of
> view of a self compiled Samba, with everything in /usr/local/samba. The
> distro place the Samba code in multiple places, so they are expected to
> provide their own documentation. The only problem is, they often do not
> get it right, if they do it at all.
> 
> Take a point in case, Centos 7 (which is based on RHEL 7) provides a
> program called 'authconfig', which, when provided with various options,
> is supposed to setup up the distro and join it to a domain. This is the
> command I used this morning:
> 
>    sudo authconfig --update --kickstart --enablewinbind --
> enablewinbindauth --smbsecurity=ads --smbworkgroup=SAMDOM --
> smbrealm=SAMDOM.EXAMPLE.COM --smbidmaprange=10000-999999 --
> winbindjoin=Administrator --winbindtemplatehomedir=/home/%U --
> winbindtemplateshell=/bin/bash --enablewinbindusedefaultdomain --
> disablesssd --disablesssdauth --enableforcelegacy --disablecachecreds
> --enablemkhomedir --enablelocauthorize --enablekrb5 --
> krb5realm=SAMDOM.EXAMPLE.COM --enablekrb5kdcdns --disablekrb5realmdns
> --enablewinbindoffline --enablewinbindkrb5
> 
> Which resulted in this:
> 
> [/usr/bin/net join -w SAMDOM  -U Administrator]
> Enter Administrator's password:
> Using short domain name -- SAMDOM
> Joined 'CEN7' to dns domain 'samdom.example.com'
> DNS Update for cen7.samdom.example.com failed: ERROR_DNS_UPDATE_FAILED
> DNS update failed: NT_STATUS_UNSUCCESSFUL
> 
> It also puts this line in /etc/samba/smb.conf
> 
>     idmap config * : range = 10000-999999
> 
> There is only that one 'idmap-config'
> 
> So what chance has red-hat getting its documentation correct, if they
> cannot write a correct smb.conf ?
> 
> If anyone thinks there is something wrong/missing in the wiki, they are
> more than welcome to edit it and perhaps we should have separate pages
> for the distro setups ?
> 

I'm not a fan of magical configuration tools; I don't use realm, either, 
for sssd deployments against Windows AD.  adcli works great and doesn't 
do things I didn't ask it to do.

I've put a little time into editing the Wiki and plan to do quite a bit 
more, time permitting.

Having separate pages for distro setups is unquestionably the right 
thing to do. When someone is starting out learning about something, they 
need an initial framework on which to stick new pieces of information. 
If this is missing they find themselves flailing about "not getting it". 
Often times when I'm learning about something new, the most effective 
learning tool is a single comprehensive example that gives me the "idea" 
of how it's supposed to work. It doesn't matter that it's not exactly or 
even that close to my use case.  Once I see how it's supposed to go, I 
can fill in the missing details myself.

People familiar with a specific distro will gravitate to documentation 
aimed at that distro.  This will allow them to more quickly grasp how 
Samba works, how it's intended to be used, and what the deployment 
idioms are.

I can write a page for Ubuntu, but likely don't have permission to set 
up a main page in the Wiki.

> Rowland
> 
> 
> 



More information about the samba mailing list