samba - Nov 2019 - Invalid PTR record in reverse lookup zone

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>

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

On Tue, Nov 12, 2019 at 07:53:06PM +0000, Rowland penny via samba
wrote:
> 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 ?
The DNS on the router is actually a dnsmasq forwarding every request ending
with (.)ad.home.arpa to the DC. So, yes the response data is comming from
the DC.
> > > 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
You're right, heave to update the OS then, another story..
> 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.
I'm very used to the "user group" scheme on Linux...
> > 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
Hmm, I did configure it on the client as suggested and it worked there.
But on the DC nothing changed. getent always returned something with
uid 30000xx. but maybe this was related to the user beeing member of
Administrators group. I have read someting about special mapping in this
case. I reverted this later on when testing with windows.
> Mine rarely breaks (and when it does, it is usually my fault through
testing
> something I shouldn't)
Thinking more about hardware issues. And absence of the maintainer during
that.

cheers,
Andreas

-------------- 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/2185c420/signature.sig>