[Samba] Invalid PTR record in reverse lookup zone

[Rowland penny]

On 12/11/2019 19:24, andi via samba wrote:
> On Mon, Nov 11, 2019 at 05:27:03PM +0000, Rowland penny via samba wrote:
>>>
>> The IP above is 192.168.183.1, yet the IP for kronos (the DC) is
>> 192.168.0.5, so it will not be fine.
> Just for my understanding: The lines "Server:" and "Address:" refer to the DNS server which
> responded the query, don't they? The actual answer to
> _kerberos._tcp.ad.home.arpa service is "0 100 88 kronos.ad.home.arpa."
> which is correct?
Yes, that is correct, BUT, it isn't coming from the DC is it ?
>
>> ...
>> You must use winbind with Samba >= 4.8.0 and this means you cannot sssd any
>> more. If you want to use the DC as a fileserver (not recommended) either use
>> idmap.ldb (the default) or nslcd.
> After another couple of hours I finally got a winbind login working.
> However I'm not sure how stable this works.
It has been very stable for myself for the last 7 years
>   On the client I had "wbinfo -i
> $username" return errors at first and suddenly it worked. Maybe related to
> the older samba 4.5.1 version on the client. I have to upgrade it anyways
> because of the primary group. (I don't want it to be "domain users")
You really should use a Samba supported version of Samba. What is wrong 
with Domain Users ? Do you not have any Windows clients ? They will 
expect (and get) Domain Users on Windows, but will get a different one 
on Unix.
>
> Yes I'm going to use the dc also as file server. I don't want to install
> multiple servers in a small home network, just an overkill. However, the
> winbind mapping on the DC is not very nice.

Use the winbind 'ad' backend on the Unix domain members and the required 
RFC2307 will replace the xidNumbers (the numbers in the 3000000 range) 
used on the DC.

Example:

root at dc4:~# getent passwd rowland
SAMDOM\rowland:*:10000:10000::/home/SAMDOM/users/rowland:/bin/bash

rowland at devstation:~/tests$ getent passwd rowland
rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash

>
> Since you said I can not set the ad idmappings on the DC, I'll have to
> live with that.
I don't think I said that.
>   I tried to manually edit idmap.ldb to enforce a uid/gid
> mapping and it seems to me that this works for file server on the DC.
> Are settings in idmap.ldb permanent? Or might they change due to some
> update command?
The DC idmappings can be changed (as shown above), but I wouldn't 
recommend editing idmap.ldb
>
>> It might appear to work, but you are loading sssd variants of winbind
>> libaries and they will conflict.
> Hmm. OK. Just a remark: I finally found the reason for the invalid
> PTR record update in the reverse lookup zone. It was sssd. It is actually
> a known problem with sssd in "ad" mode. It uses gethostname() and expects
> it to be the fqdn. Then it invokes "adcli" with the hostname to set the
> PTR record, which is then wrong since gethostname() does not return the
> fqdn in all configurations.
This 'might' be one problem, but there are numerous other ones and as I 
said, using sssd with Samba >= 4.8.0 is not supported, even red-hat says 
that.
>
>> ...
>> That is not what I said, provisioning with RFC2307 only adds various OUs etc
>> in AD, it does not add any of the RFC2307 attributes and you need these for
>> the winbind 'ad' backend to work. If you haven't added any RFC2307
>> attributes to AD, then use 'rid' on the Unix domain members
> I already added them (sssd required them also)
>
>> Can I point out that your set up is very like mine and everything works for
>> me, I use the router as just that, everything else is done by the DCs. I
>> suggest you read these:
> Thanks for the links. Well, I tend to have my system as much error prone
> and also "non linux specialist maintainable (wife :-)" as possible.
> Browsing the internet should work in any case, even if the DC machine is
> completely broken.
Mine rarely breaks (and when it does, it is usually my fault through 
testing something I shouldn't)
>
> So far, thank you very much for your help. I was short before just going
> back to LDAP + Kerberos and forget about Windows Logon and Shares. In some
> parts it is really hard to track down problems with samba, the error
> reporting could be more informative in some cases.
Do not even consider Samba, ldap etc, they rely on SMBv1 and this is 
very likely to be removed.
>
> I'm gonna do a little more testing now to see if the configuration is
> somewhat stable and fits my needs.

It all works for me and has done since 2012, it just needs to be set up 
correctly.

Rowland