Bug 12807 - RSAT DNS Unusable - auth_level_connect access to [dnsserver] bug
RSAT DNS Unusable - auth_level_connect access to [dnsserver] bug
Status: NEW
Product: Samba 4.1 and newer
Classification: Unclassified
Component: DCE-RPCs and pipes
4.5.10
All All
: P5 critical
: ---
Assigned To: Andrew Bartlett
Samba QA Contact
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-05-28 21:49 UTC by Phillip R. Jaenke
Modified: 2017-05-29 18:08 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Phillip R. Jaenke 2017-05-28 21:49:37 UTC
This is unquestionably a major regression at this point. In an even trivially complex configuration, users will endlessly encounter this message: 

dcesrv_request: restrict auth_level_connect access to [dnsserver] with auth[type=0xa,level=0x2] on [ncacn_ip_tcp] from [ipv4:10.10.1.38:57071]

The root cause is Samba failing to handle network addresses properly somewhere. This was introduced in 4.5.8. The Samba DC in question has the following IP addresses:

ue0: 10.10.0.90
lo0: 10.53.0.1 - BGP Anycast DNS
lo0: 10.53.0.2 - BGP Anycast DNS

Access is continually denied to 10.10.0.90 for the DNS snap-in. This occurs even when 'bind interfaces only' is set and 'interfaces' is set to "ue0 127.0.0./32". However, if 'bind interfaces only' is NOT set, 10.10.0.90 will refuse with this error while 10.53.0.1 works.
This will occur when a domain is interactively or non-interactively provisioned. Samba does select the correct IP address of 10.10.0.90 but does NOT properly configure for it. Instead it configures DNS access for the BGP anycast IP address, while reporting the correct address to all outputs and also configuring domain DNS records correctly.

Observe:
root@skyhorn # samba-tool domain provision --adminpass=REMOVED --use-rfc2307 --dns-backend=BIND9_DLZ --host-name=SKYHORN --host-ip=10.10.0.90 --host-ip6=REMOVED::90 --function-level=2008_R2 --domain=TEST--realm=TEST.PVT

RSAT gets access denied.

root@skyhorn:~ # host skyhorn
skyhorn.rootwyrm.pvt has address 10.10.0.90
skyhorn.rootwyrm.pvt has IPv6 address REMOVED::90
root@skyhorn:~ # ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
        groups: lo
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
ue0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=80009<RXCSUM,VLAN_MTU,LINKSTATE>
        ether b8:27:eb:af:e2:58
        inet 10.10.0.90 netmask 0xfffffe00 broadcast 10.10.1.255
        inet6 fe80::ba27:ebff:feaf:e258%ue0 prefixlen 64 scopeid 0x2
        inet6 REMOVED::90 prefixlen 48
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

root@skyhorn:~ # /etc/rc.d/netif restart
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
ifconfig: ioctl (SIOCDIFADDR): Can't assign requested address
Starting Network: lo0 ue0.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
        options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
        inet 127.0.0.1 netmask 0xff000000
        inet 10.53.0.1 netmask 0xffffffff
        inet 10.53.0.2 netmask 0xffffffff
        groups: lo
...
root@skyhorn:~ # service quagga start
Checking zebra.conf OK
Starting zebra.
Checking bgpd.conf OK
Starting bgpd.

RSAT: Connect to 10.10.0.90
 dcesrv_request: restrict auth_level_connect access to [dnsserver] with auth[type=0xa,level=0x2] on [ncacn_ip_tcp] from [ipv4:10.10.1.50:58195]

RSAT: Connect to 10.53.0.1: OK, no message
RSAT: Connect to 10.53.0.2: OK, no message

This occurs on multiple versions of Windows, on machines joined to the domain and machines using RUNAS.
Comment 1 Andrew Bartlett 2017-05-28 22:24:03 UTC
The line in the log refers This would have broken with the BadLock fixes in CVE-2016-2118 back on on Samba 4.4.2

The workaround is "allow dcerpc auth level connect = yes" or more specifically "allow dcerpc auth level connect:dnsserver = yes"

I don't see how this is connected with IP ranges or the other things you are seeing, except to say that the fallback to NTLMSSP appears to be failing, perhaps when Kerberos is successful it works.
Comment 2 Andrew Bartlett 2017-05-28 22:25:11 UTC
(In reply to Andrew Bartlett from comment #1)
err, The line in the log you highlight refers to a change made with BadLock fixes in CVE-2016-2118 back on on Samba 4.4.2.
Comment 3 Phillip R. Jaenke 2017-05-28 23:20:19 UTC
Sorry, had some serious trouble shuffling out the logs due to the environment being very noisy. Probably did a poor job of explaining it, as well. So let me take another swing at it.

With 'allow dcerpc auth level connect' not set, the OBSERVED behavior of Samba 4.5.10 is this:
10.10.0.90: DNS denied, all others permitted with appropriate authentication
10.53.0.1:  All RPC permitted, no authentication observed
10.53.0.2:  All RPC permitted, no authentication observed

Obviously, the behavior EXPECTED would be this:
10.10.0.90: DNS denied, all others permitted
10.53.0.1:  All denied
10.53.0.2:  All denied

In other words, Samba is not actually checking properly in this configuration and as a result permits basically even normal users access to 'dnsserver' on the addresses on lo0. It does this even when it is explicitly told to NOT bind to the 10.53.0.[1,2] addresses as well - which I would say is not desirable behavior. (The whole reason for not binding to them is that if permitted to bind, it includes the anycast addresses as candidates for the top level A and other definitely-not-good-practices behaviors.)
To contrast, on 4.5.7 the behavior observed was as desired; 10.10.0.90 permitted all RPC for authenticated users with appropriate permissions, and denied all on the anycast addresses.

That's why I'm suspecting a regression somewhere in 4.5.8; this behavior wasn't observed in 4.5.7 using the same exact config and the same domain. Upgrading to 4.5.8 triggered it. 
While the 'allow dcerpc' may be required, it should be rejecting on ALL addresses. Instead, it only rejects on the interface Samba is explicitly bound to. The inverse of what one would expect. And the accesses on the anycast address do not appear to be subjected to any checks; it's as though they're acting as the DC itself.
Comment 4 Phillip R. Jaenke 2017-05-29 18:08:54 UTC
Results of further testing. Client is Windows 2012R2 with all of the latest security patches, but does NOT have 05-2017 Quality rollup. This is starting to look something is behaving very inconsistently.

WITH 'allow dcerpc auth level connect:dnsserver = yes' in smb4.conf, ALL IPs deny access to DNS snap-in as TEST\Administrator.
  dcesrv_request: restrict access by min_auth_level[0x5] to [dnsserver] with auth[type=0xa,level=0x2] on [ncacn_ip_tcp] from [ipv4:10.10.1.38:52205]

WITH 'allow dcerpc auth level connect = yes' in smb4.conf, ALL IPs deny access to DNS snap-in.
  dcesrv_request: restrict access by min_auth_level[0x5] to [dnsserver] with auth[type=0xa,level=0x2] on [ncacn_ip_tcp] from [ipv4:10.10.1.38:52209]

WITHOUT 'allow dcerpc auth level' set, ALL IPs deny access to DNS snap-in.
  dcesrv_request: restrict auth_level_connect access to [dnsserver] with auth[type=0xa,level=0x2] on [ncacn_ip_tcp] from [ipv4:10.10.1.38:52201]

This may be related, or may even be the root cause. This is, again, on a completely clean system with an entirely fresh domain provision. There is clearly an off-by-one error going on in gensec_gssapi_update.

[2017/05/29 13:51:28.538292,  1] ../source4/auth/gensec/gensec_gssapi.c:622(gensec_gssapi_update)
  GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see text): Failed to find SKYHORN$@TEST.PVT(kvno 2) in keytab FILE:/var/db/samba4/private/secrets.keytab (aes256-cts-hmac-sha1-96)
[2017/05/29 13:52:28.611454,  1] ../source4/auth/gensec/gensec_gssapi.c:622(gensec_gssapi_update)
  GSS server Update(krb5)(1) Update failed:  Miscellaneous failure (see text): Failed to find SKYHORN$@TEST.PVT(kvno 2) in keytab FILE:/var/db/samba4/private/secrets.keytab (aes256-cts-hmac-sha1-96)
[2017/05/29 13:55:00.372775,  2] ../source4/dsdb/kcc/kcc_periodic.c:711(kccsrv_samba_kcc)
  Calling samba_kcc script

The KVNO is being shifted by 1 here somewhere. The actual KVNO is 1.
root@skyhorn # ktutil -k /var/db/samba4/private/secrets.keytab list | grep SKYHORN
  1  des-cbc-crc              SKYHORN$@TEST.PVT
  1  des-cbc-md5              SKYHORN$@TEST.PVT
  1  arcfour-hmac-md5         SKYHORN$@TEST.PVT
  1  aes128-cts-hmac-sha1-96  SKYHORN$@TEST.PVT
  1  aes256-cts-hmac-sha1-96  SKYHORN$@TEST.PVT

root@skyhorn # samba_spnupdate -d 10
... trimmed ...
pm_process() returned Yes
Security token SIDs (1):
  SID[  0]: S-1-5-18
 Privileges (0xFFFFFFFFFFFFFFFF):
  Privilege[  0]: SeMachineAccountPrivilege
  Privilege[  1]: SeTakeOwnershipPrivilege
  Privilege[  2]: SeBackupPrivilege
  Privilege[  3]: SeRestorePrivilege
  Privilege[  4]: SeRemoteShutdownPrivilege
  Privilege[  5]: SePrintOperatorPrivilege
  Privilege[  6]: SeAddUsersPrivilege
  Privilege[  7]: SeDiskOperatorPrivilege
  Privilege[  8]: SeSecurityPrivilege
  Privilege[  9]: SeSystemtimePrivilege
  Privilege[ 10]: SeShutdownPrivilege
  Privilege[ 11]: SeDebugPrivilege
  Privilege[ 12]: SeSystemEnvironmentPrivilege
  Privilege[ 13]: SeSystemProfilePrivilege
  Privilege[ 14]: SeProfileSingleProcessPrivilege
  Privilege[ 15]: SeIncreaseBasePriorityPrivilege
  Privilege[ 16]: SeLoadDriverPrivilege
  Privilege[ 17]: SeCreatePagefilePrivilege
  Privilege[ 18]: SeIncreaseQuotaPrivilege
  Privilege[ 19]: SeChangeNotifyPrivilege
  Privilege[ 20]: SeUndockPrivilege
  Privilege[ 21]: SeManageVolumePrivilege
  Privilege[ 22]: SeImpersonatePrivilege
  Privilege[ 23]: SeCreateGlobalPrivilege
  Privilege[ 24]: SeEnableDelegationPrivilege
 Rights (0x               0):
lpcfg_servicenumber: couldn't find ldb
lpcfg_servicenumber: couldn't find ldb
Initial schema load needed, as we have no existing schema, seq_num: 2
schema_fsmo_init: we are master[yes] updates allowed[no]
Initial schema load needed, as we have no existing schema, seq_num: 2
schema_fsmo_init: we are master[yes] updates allowed[no]

root@skyhorn /var/db/samba4/private # ldbsearch -H secrets.ldb
# record 1
dn: flatname=TEST,cn=Primary Domains
msDS-KeyVersionNumber: 1
...trimmed...
# record 4
dn: samAccountName=dns-SKYHORN,CN=Principals
msDS-KeyVersionNumber: 1

So the LDB is saying that it is KVNO 1, the keytab has KVNO 1, but Samba is looking for KVNO 2 for both the host AND DNS principals.