samba - Aug 2016 - Samba 4.2.14 Group Policy (GPO) sync error

Hi Louis,

> Ive tested the following, i use static and dhcp ip here.
I am using DHCP only.
> Everything on static ip works perfect on win7 and win10.
> And at the domain join the a and ptr is created automaticly.
> GPO works fine for both.
Can't tell about static setup as it's impractical in my networks.

> Dhcp ip.
> Win 7 works fine, AD join A and PTR is created and updated when the ip is
changes. GPO works fine.
Was it a fully patched Widndows 7 Pro? As my one still complains about 
being unable to hange the name on domain join and also it fails to 
update GPO.

> Win 10 works, AD join A and PTR is created and but not updated when the ip
is changes. GPO works fine until the ip is updated
> So i'll look into the "why" the ptr is not updated on win10.
> Besides that it looks normal here.
Alright, but I doubt this will solve my problem. It probebly just showed 
another problem with Samba which is only partially related. Because my 
IPs don't change very often even with DHCP setup it should actually work 
for me at least right after Domain join.


>Rainer,
> I dont think there is an inssue with your install.
> But i would change the krb5.conf to but im no kerberos guru, i would think
its something like below what you need.

I did change my krb5.conf exactly to what you proposed (first proposal 
with dns_lookup_realm = false and realm defined), then restarted Samba 
and still renter into the same issue.

gpupdate:
The processing of Group Policy failed. Windows could not resolve the 
computer name. This could be caused by one of more of the following:
a) Name Resolution failure on the current domain controller.
b) Active Directory Replication Latency (an account created on another 
domain controller has not replicated to the current domain controller).
User Policy could not be updated successfully. The following errors were 
encountered:

The processing of Group Policy failed. Windows could not resolve the 
user name. This could be caused by one of more of the following:
a) Name Resolution failure on the current domain controller.
b) Active Directory Replication Latency (an account created on another 
domain controller has not replicated to the current domain controller).

To diagnose the failure, review the event log or run GPRESULT /H 
GPReport.html from the command line to access information about Group 
Policy results.


This happens on at least 3 classicupgraded Samba installations here.


Any idea how to trace it down?

best regards,
Rainer

Am 08.08.2016 um 22:44 schrieb rme at bluemail.ch:
> Hi Louis,
>
>
>> Ive tested the following, i use static and dhcp ip here.
>
> I am using DHCP only.
>
>> Everything on static ip works perfect on win7 and win10.
>> And at the domain join the a and ptr is created automaticly.
>> GPO works fine for both.
>
> Can't tell about static setup as it's impractical in my networks.
>
>
>> Dhcp ip.
>> Win 7 works fine, AD join A and PTR is created and updated when the 
>> ip is changes. GPO works fine.
>
> Was it a fully patched Widndows 7 Pro? As my one still complains about 
> being unable to hange the name on domain join and also it fails to 
> update GPO.
>
>
>> Win 10 works, AD join A and PTR is created and but not updated when 
>> the ip is changes. GPO works fine until the ip is updated
>> So i'll look into the "why" the ptr is not updated on
win10.
>> Besides that it looks normal here.
>
> Alright, but I doubt this will solve my problem. It probebly just 
> showed another problem with Samba which is only partially related. 
> Because my IPs don't change very often even with DHCP setup it should 
> actually work for me at least right after Domain join.
>
>
>
>> Rainer,
>> I dont think there is an inssue with your install.
>> But i would change the krb5.conf to but im no kerberos guru, i would 
>> think its something like below what you need.
>
>
> I did change my krb5.conf exactly to what you proposed (first proposal 
> with dns_lookup_realm = false and realm defined), then restarted Samba 
> and still renter into the same issue.
>
> gpupdate:
> The processing of Group Policy failed. Windows could not resolve the 
> computer name. This could be caused by one of more of the following:
> a) Name Resolution failure on the current domain controller.
> b) Active Directory Replication Latency (an account created on another 
> domain controller has not replicated to the current domain controller).
> User Policy could not be updated successfully. The following errors 
> were encountered:
>
> The processing of Group Policy failed. Windows could not resolve the 
> user name. This could be caused by one of more of the following:
> a) Name Resolution failure on the current domain controller.
> b) Active Directory Replication Latency (an account created on another 
> domain controller has not replicated to the current domain controller).
>
> To diagnose the failure, review the event log or run GPRESULT /H 
> GPReport.html from the command line to access information about Group 
> Policy results.
>
>
> This happens on at least 3 classicupgraded Samba installations here.
>
>
> Any idea how to trace it down?
>
> best regards,
> Rainer
>
Hello Rainer,

I remember this error. In my case the pc tried to connect to the gpo 
share not via the server name but via the domain name. In your case 
ad.cyberdyne.local.
In my case the domain name sometimes  resolved to ad dc servers in 
subnet whom where not reachable from the client pc so the connection failed.
Can you browse ad.cyberdyne.local from your client pc? And can it be you 
also have addc servers in other non reachable subnets.

Achim~

Hi Achim,

Thanks a lot for your reply.

> I remember this error. In my case the pc tried to connect to the gpo
> share not via the server name but via the domain name. In your case
> ad.cyberdyne.local.

Well, I am even able to browser the policies via the domain name:
\\ad.cyberdyne.local\sysvol\ad.cyberdyne.local\Policies
Or via hostname:
\\skynet.ad.cyberdyne.local\sysvol\ad.cyberdyne.local\Policies

It's all working just fine.

> In my case the domain name sometimes  resolved to ad dc servers in
> subnet whom where not reachable from the client pc so the connection
failed.
> Can you browse ad.cyberdyne.local from your client pc? And can it be you
> also have addc servers in other non reachable subnets.
Actually my trusted clients are in 10.0.1.0/24 subnet.
Untrusted clients are in 10.0.2.0/24 subnet but this subnet does not 
contain ad-joined hosts.
Samba listens on 3 IPs:
- 10.0.1.6
- 10.0.1.6
- fdea:5b48:d4c1:1:1::6

DNS also resolves those hosts:
>nslookup skynet
Server:  skynet.ad.cyberdyne.local
Address:  fdea:5b48:d4c1:1:1::6

Name:    skynet.ad.cyberdyne.local
Addresses:  fdea:5b48:d4c1:1:1::6
           10.0.2.6
           10.0.0.6
           10.0.1.6


Actually the routes and firewalls also allo unlimited connection from 
10.0.1.0/24 to 10.0.2.0/24.

Though as you brought up the topic I tested to connect to 
\\10.0.2.6\sysvol from my 10.0.1.x machine. The connection works OK but 
somehow I am prompted to enter the password and it does not accept it. 
However I don't know why yet.
The same applies to the IPv6 connection at 
\\fdea-5b48-d4c1-1-1--6.ipv6-literal.net\sysvol.
It seems I cannot authenticate on any listener interface other than the 
main 10.0.1.6 listening address.

I don't know yet what the reason for this is. I also tried this in smb.conf:
     interfaces = 10.0.1.6/24
     bind interfaces only = true

Now samba only listens on 10.0.1.6 but still samba_dlz resolves all IP 
adresses for skynet.ad.cyberdyne.local.
Then I reset my complete samba_dlz installation (removing keytab, user 
and private/dns folder entirely) and re-initialized it. Then restarted 
named too and run "samba_dnsupdate --all-names".

Now DNS resolved as follows:
>nslookup skynet.ad.cyberdyne.local
Server:  skynet.ad.cyberdyne.local
Address:  fdea:5b48:d4c1:1:1::6

Name:    skynet.ad.cyberdyne.local
Address:  10.0.1.6
           10.0.0.6

I have no idea at all why Samba still resolves to 10.0.0.6 as it does 
not listen on this interface. Yes this inteface exists and 10.0.0.0/24 
is used on a dedicated physical network interface. But I don't want 
Samba to listen on it and the interfaces line (see above) does not list 
it. Netstat confirms Samba does not listen on this interface.

So I removed the entry manually:
     samba-tool dns delete skynet.ad.cyberdyne.local ad.cyberdyne.local 
skynet A 10.0.0.6

Now DNS looks alright, IPv4 only:
>nslookup skynet.ad.cyberdyne.local
Server:  skynet.ad.cyberdyne.local
Address:  fdea:5b48:d4c1:1:1::6

Name:    skynet.ad.cyberdyne.local
Address:  10.0.1.6


To also exclude any possible issue with IPv6 I also disabled IPv6 on my 
testing client.
Now from the client I am able to connect to 
\\skynet.ad.cyberdyne.local\sysvol, but get access-denied on 
\\10.0.1.6\sysvol, no matter which account I try.


Also when I do 'samba_dnsupdate --all-names' I see the following in the 
logs (repeated) but no error reported.

[2016/08/09 20:41:33.748195,  3] 
../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
   Kerberos: AS-REQ named at AD.CYBERDYNE.LOCAL from ipv4:10.0.1.6:33531 
for krbtgt/AD.CYBERDYNE.LOCAL at AD.CYBERDYNE.LOCAL
[2016/08/09 20:41:33.749880,  3] 
../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper)
   Kerberos: UNKNOWN -- named at AD.CYBERDYNE.LOCAL: no such entry found in hdb


So something might be fishy in samba code to bind to multiple network 
interaces:
- Samba partially ignores the intefaces directive
- Somehow I can only connect to the first interface, not to any other IP


best regards,
Rainer

OK, I actually now feel a bit bad on this. As we did a lot of debugging 
without actually finding any solutions my focus went more and more into 
direction of code bug somewhere in Samba/Kerberos area.

I found some references that Samba uses an internal specific version of 
Heimdal. Though it looks like the Gentoo developers went to disable the 
built-in Heimdal implementation if favor of a system-wide Heimdal. 
Currently Gentoo uses Heimdal 1.5.3-r2. On the official page 
(http://www.h5l.org/) I see only release 1.5.2 officially listed (??).
Moreover I found the samba package enforces disabling SSL on Heimdal. 
This seems to be required as the built-in Heimdal crypto library 
(hcrypto) is built only if openssl support is disabled in Heimdal. I 
left this unchanged then.


So I went deeper and found the Samba ebuild to explicitly disable 
bundled packages (configure options):

         --bundled-libraries=NONE
         --builtin-libraries=NONE


I quickly removed both lines. The effect was that Samba now fails to 
compile complaining about tgt_use_strongest_session_key. I found this to 
be an issue of a patch applied by the Gentoo team:

--- samba-4.2.3/source4/kdc/kdc.c
+++ samba-4.2.3/source4/kdc/kdc.c
@@ -967,9 +967,9 @@
          * The old behavior in the _kdc_get_preferred_key()
          * function is use_strongest_server_key=TRUE.
          */
-       kdc->config->as_use_strongest_session_key = false;
+       kdc->config->tgt_use_strongest_session_key = false;
         kdc->config->preauth_use_strongest_session_key = false;
-       kdc->config->tgs_use_strongest_session_key = false;
+       kdc->config->svc_use_strongest_session_key = false;
         kdc->config->use_strongest_server_key = true;

As I am using bundled/built-in Heimdal now I simply also removed this patch.

Now Samba compiled and seems to work. Even my group policies seem to 
apply correctly.


So as a result it looks like Samba works well with the built-in (perhaps 
modified?) Heimdal library but does not with the Gentoo Heimdal 1.5.3 
ebuild. I am not sure if the patch listed above is actually correct. So 
I went back disabling bundled and built-in libraries again and leaving 
the patch disabled.

This breaks the build:

../source4/kdc/kdc.c:970:13: error: ‘krb5_kdc_configuration’ has no 
member named ‘as_use_strongest_session_key’
   kdc->config->as_use_strongest_session_key = false;
              ^
../source4/kdc/kdc.c:972:13: error: ‘krb5_kdc_configuration’ has no 
member named ‘tgs_use_strongest_session_key’
   kdc->config->tgs_use_strongest_session_key = false;


Well, I am not sure if the built-in Heimdal within the Samba package is 
patched/modified in any way. In general I would say Samba should work 
with a system-wide Heimdal installation too which is obviously not the 
case. Though this might be an insufficiency of the Gentoo Heimdal 
ebuild. I think actually the Gentoo team is right that a system-wide 
Heimdal should be used and not bundled libraries - if possible. Though 
there seems to be some incompatibility.


So currently my solution is to use a custom ebuild allowing bundled 
libraries and removing the custom Gentoo patch.

# diff /usr/portage/net-fs/samba/samba-4.2.14.ebuild samba-4.2.14.ebuild
93c93
<       "${FILESDIR}/${PN}-4.2.3-heimdal_compilefix.patch"
---
>       # "${FILESDIR}/${PN}-4.2.3-heimdal_compilefix.patch"
143,144c143,144
<               --bundled-libraries=NONE
<               --builtin-libraries=NONE
---
>               # --bundled-libraries=NONE
>               # --builtin-libraries=NONE
258a259
>
I will report this to the Gentoo team so they can perhaps investigate on 
how to fix Samba using system-wide Heimdal.


Many many thanks to the people involved here helping me to debug the 
issue. I have learned a lot about Sabma internals and perhaps this is 
helpful for others too. I still don't know exactly what goes wrong as 
the complete Samba build of Gentoo works fine and the logs don't show 
something which is obviously wrong.

With best regards,
Rainer

The bug report is submitted here:
<https://bugs.gentoo.org/show_bug.cgi?id=591212>

Am 13.08.2016 um 22:47 schrieb Rainer Meier via samba:
> OK, I actually now feel a bit bad on this. As we did a lot of 
> debugging without actually finding any solutions my focus went more 
> and more into direction of code bug somewhere in Samba/Kerberos area.
>
> I found some references that Samba uses an internal specific version 
> of Heimdal. Though it looks like the Gentoo developers went to disable 
> the built-in Heimdal implementation if favor of a system-wide Heimdal. 
> Currently Gentoo uses Heimdal 1.5.3-r2. On the official page 
> (http://www.h5l.org/) I see only release 1.5.2 officially listed (??).
> Moreover I found the samba package enforces disabling SSL on Heimdal. 
> This seems to be required as the built-in Heimdal crypto library 
> (hcrypto) is built only if openssl support is disabled in Heimdal. I 
> left this unchanged then.
>
>
> So I went deeper and found the Samba ebuild to explicitly disable 
> bundled packages (configure options):
>
>         --bundled-libraries=NONE
>         --builtin-libraries=NONE
>
>
> I quickly removed both lines. The effect was that Samba now fails to 
> compile complaining about tgt_use_strongest_session_key. I found this 
> to be an issue of a patch applied by the Gentoo team:
>
> --- samba-4.2.3/source4/kdc/kdc.c
> +++ samba-4.2.3/source4/kdc/kdc.c
> @@ -967,9 +967,9 @@
>          * The old behavior in the _kdc_get_preferred_key()
>          * function is use_strongest_server_key=TRUE.
>          */
> -       kdc->config->as_use_strongest_session_key = false;
> +       kdc->config->tgt_use_strongest_session_key = false;
>         kdc->config->preauth_use_strongest_session_key = false;
> -       kdc->config->tgs_use_strongest_session_key = false;
> +       kdc->config->svc_use_strongest_session_key = false;
>         kdc->config->use_strongest_server_key = true;
>
> As I am using bundled/built-in Heimdal now I simply also removed this 
> patch.
>
> Now Samba compiled and seems to work. Even my group policies seem to 
> apply correctly.
>
>
> So as a result it looks like Samba works well with the built-in 
> (perhaps modified?) Heimdal library but does not with the Gentoo 
> Heimdal 1.5.3 ebuild. I am not sure if the patch listed above is 
> actually correct. So I went back disabling bundled and built-in 
> libraries again and leaving the patch disabled.
>
> This breaks the build:
>
> ../source4/kdc/kdc.c:970:13: error: ‘krb5_kdc_configuration’ has no 
> member named ‘as_use_strongest_session_key’
>   kdc->config->as_use_strongest_session_key = false;
>              ^
> ../source4/kdc/kdc.c:972:13: error: ‘krb5_kdc_configuration’ has no 
> member named ‘tgs_use_strongest_session_key’
>   kdc->config->tgs_use_strongest_session_key = false;
>
>
> Well, I am not sure if the built-in Heimdal within the Samba package 
> is patched/modified in any way. In general I would say Samba should 
> work with a system-wide Heimdal installation too which is obviously 
> not the case. Though this might be an insufficiency of the Gentoo 
> Heimdal ebuild. I think actually the Gentoo team is right that a 
> system-wide Heimdal should be used and not bundled libraries - if 
> possible. Though there seems to be some incompatibility.
>
>
> So currently my solution is to use a custom ebuild allowing bundled 
> libraries and removing the custom Gentoo patch.
>
> # diff /usr/portage/net-fs/samba/samba-4.2.14.ebuild samba-4.2.14.ebuild
> 93c93
> <       "${FILESDIR}/${PN}-4.2.3-heimdal_compilefix.patch"
> ---
>>       # "${FILESDIR}/${PN}-4.2.3-heimdal_compilefix.patch"
> 143,144c143,144
> <               --bundled-libraries=NONE
> <               --builtin-libraries=NONE
> ---
>>               # --bundled-libraries=NONE
>>               # --builtin-libraries=NONE
> 258a259
>>
>
> I will report this to the Gentoo team so they can perhaps investigate 
> on how to fix Samba using system-wide Heimdal.
>
>
> Many many thanks to the people involved here helping me to debug the 
> issue. I have learned a lot about Sabma internals and perhaps this is 
> helpful for others too. I still don't know exactly what goes wrong as 
> the complete Samba build of Gentoo works fine and the logs don't show 
> something which is obviously wrong.
>
> With best regards,
> Rainer
>
Glad you firgured it out and thank you for the detailed infos. There was 
an discussion here about the move to mit kerberos in the future. Heimdal 
is not actively developed any more, so the samba team manages required 
modifications internally.
I remember I got the unknown mech error messages related to missing sasl 
libraries when using ldap-tools.