[Samba] Invalid PTR record in reverse lookup zone

[andi]

On Mon, Nov 11, 2019 at 05:27:03PM +0000, Rowland penny via samba wrote:
> > > > Kerberos SRV _kerberos._tcp.ad.home.arpa record verified ok, sample output:
> > > > Server:		192.168.183.1
> > > > Address:	192.168.183.1#53
> > > > 
> > > > _kerberos._tcp.ad.home.arpa	service = 0 100 88 kronos.ad.home.arpa.
> > > > Samba is running as an AD DC
> > > Interesting, the kerberos record should point to the DC, it seems to be
> > > pointing to the router.
> > Why? Kronos is the DC. So it should be fine.
> 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?

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

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. 

Since you said I can not set the ad idmappings on the DC, I'll have to
live with 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?

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

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

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. 

I'm gonna do a little more testing now to see if the configuration is
somewhat stable and fits my needs.

cheers,
Andreas

-- 
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba/attachments/20191112/7e43c9a2/signature.sig>