[Samba] Samba 4 "Classic PDC" trusts fail with Win 2012 domain but succeed Win 2008
Gaiseric Vandal
gaiseric.vandal at gmail.com
Tue Nov 22 17:04:57 UTC 2016
I am trying to configuring Samba 4 classic PDC to trust Windows 2012
domain "DomainB" - the PDC is running Windows 2012 but the forest and
domain functional levels are still Windows 2008. On the Win 2012 PDC I
try to set up an incoming trust, but it fails with "The local security
authority is unable to obtain an RPC connection to the active directory
domain controller SAMBAPDC . "
I have an third domain "DomainC" - the PDC is running Windows 2008 ,
and the forest and domain functional levels are still Windows 2008.
On that PDC I am able to configure and verify an incoming trust.
I am guessing some recent security patch that applies to Windows 2012
but not to Windows 2008 is the issue?
Since samba is a configured as a classic domain, I would have expected
the Windows 2012 DC to see the samba domain as an NT4 domain.
I have tried setting the following in smb.conf
server services = +smb -s3fs
dcerpc endpoint servers = +winreg +srvsvc
max protocol = nt1
client signing = auto
client ipc signing = autoserver signing = auto
allow dcerpc auth level connect = yes
No luck.
Appreciate any feedback or advice.
On 11/18/16 10:48, Gaiseric Vandal wrote:
> I tried recreating the trusts.
>
> I start by setting up trusts on Windows side, using Active Directory
> Domains and Trusts on the DomainB AD server. . I specify the the
> samba domain (DOMAINB) but before I can even specify trust type or
> direction I get the following:
>
> Cannot continue
>
> Trust relationship can not be created…
> The local security authority is unable to obtain an RPC connection
> to the active directory domain controller SAMBAPDC .
> Please check that the name can be resolved and the server is
> available.
>
>
>
>
> So clearly by DNS or WINS the AD server has located the correct domain
> controller for the samba domain.
>
>
> # nmap -Pn SAMBAPDC
>
> PORT STATE SERVICE
> 22/tcp open ssh
> 88/tcp open kerberos-sec
> 111/tcp open rpcbind
> 139/tcp open netbios-ssn
> 389/tcp open ldap
> 445/tcp open microsoft-ds
> 636/tcp open ldapssl
> 4045/tcp open lockd
> 8654/tcp open unknown
>
>
>
>
> The server is running a kerberos and LDAP server independent of any
> samba services so port 88, 389 and 636 are not samba related. This
> is a "classic" samba domain. (nmap only scanned for TCP ports not UDP)
>
> According to the following link TCP port 135 should also be open.
>
> https://wiki.samba.org/index.php/Samba_NT4_PDC_Port_Usage
>
>
>
> I don't remember if TCP port 135 was open when I used samba 3.x domain
> controllers. The testparm command shows "allow dcerpc auth level
> connect = No" (which was not a parameter available with samba 3.x)
>
> Thanks
>
>
>
>
>
>
>
> On 11/17/16 16:38, Gaiseric Vandal wrote:
>> I updated my PDC and BDC to Samba 4.4.7. Compiled from source
>> into /usr/local/samba.
>>
>>
>>
>> On the samba domain controllers
>>
>> "/usr/local/samba/bin/wbinfo -u" shows the local domain users but not
>> the trusted one.
>>
>> Everything indicates trusts are ok
>>
>>
>> # /usr/local/samba/bin/net rpc trustdom list -U Administrator
>> Enter Administrator's password:
>> Trusted domains list:
>>
>> DOMAINB S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx
>>
>> Trusting domains list:
>>
>> DOMAINB S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx
>> #
>>
>> #/usr/local/samba/bin/wbinfo --all-domains
>> BUILTIN
>> DOMAINA
>> DOMAINB
>>
>>
>>
>>
>> The log.wb-DOMAINB file shows
>>
>> [2016/11/17 16:22:02.091057, 1]
>> ../source3/winbindd/winbindd_ads.c:136(ads_cached_connection_connect)
>> ads_connect for domain DOMAINB failed: The request is not
>> supported.
>> [2016/11/17 16:24:44.932829, 3]
>> ../source3/winbindd/winbindd_pam.c:2058(winbindd_dual_pam_auth_crap)
>> [ 1578]: pam auth crap domain: administration user:
>> administrator
>> [2016/11/17 16:24:44.936346, 3]
>> ../source3/winbindd/winbindd_ads.c:1488(sequence_number)
>> ads: fetch sequence_number for DOMAINB
>> [2016/11/17 16:24:44.936534, 2]
>> ../source3/lib/smbldap.c:794(smbldap_open_connection)
>> smbldap_open_connection: connection opened
>> [2016/11/17 16:24:44.938529, 3]
>> ../source3/lib/smbldap.c:1013(smbldap_connect_system)
>> ldap_connect_system: successful connection to the LDAP server
>> [2016/11/17 16:24:44.939117, 3]
>> ../source3/libsmb/namequery.c:3117(get_dc_list)
>> get_dc_list: preferred server list:
>> "DS1.domainb.mydomain.com, *"
>> [2016/11/17 16:24:44.940870, 3]
>> ../source3/libads/ldap.c:618(ads_connect)
>> Successfully contacted LDAP server 192.168.3.26
>> [2016/11/17 16:24:44.941023, 3]
>> ../source3/libsmb/namequery.c:3117(get_dc_list)
>> get_dc_list: preferred server list:
>> "DS1.domainb.mydomain.com, *"
>> [2016/11/17 16:24:44.942361, 3]
>> ../source3/libads/ldap.c:618(ads_connect)
>> Successfully contacted LDAP server 192.168.x.x
>> [2016/11/17 16:24:44.943591, 3]
>> ../source3/libads/ldap.c:618(ads_connect)
>> Successfully contacted LDAP server 192.168.x.x.
>> [2016/11/17 16:24:44.944318, 3]
>> ../source3/libads/ldap.c:661(ads_connect)
>> Connected to LDAP serverDS1.domainb.mydomain.com
>> [2016/11/17 16:24:44.946468, 3]
>> ../source3/libads/sasl.c:733(ads_sasl_spnego_bind)
>> ads_sasl_spnego_bind: got OID=1.3.6.1.4.1.311.2.2.30
>> [2016/11/17 16:24:44.946532, 3]
>> ../source3/libads/sasl.c:733(ads_sasl_spnego_bind)
>> ads_sasl_spnego_bind: got OID=1.2.840.48018.1.2.2
>> [2016/11/17 16:24:44.946574, 3]
>> ../source3/libads/sasl.c:733(ads_sasl_spnego_bind)
>> ads_sasl_spnego_bind: got OID=1.2.840.113554.1.2.2
>> [2016/11/17 16:24:44.946614, 3]
>> ../source3/libads/sasl.c:733(ads_sasl_spnego_bind)
>> ads_sasl_spnego_bind: got OID=1.2.840.113554.1.2.2.3
>> [2016/11/17 16:24:44.946655, 3]
>> ../source3/libads/sasl.c:733(ads_sasl_spnego_bind)
>> ads_sasl_spnego_bind: got OID=1.3.6.1.4.1.311.2.2.10
>> [2016/11/17 16:24:45.250387, 0]
>> ../source3/libads/sasl.c:336(ads_sasl_spnego_gensec_bind)
>> ads_setup_sasl_wrapping() failed: The request is not supported.
>> [2016/11/17 16:24:45.256988, 0]
>> ../source3/libads/sasl.c:779(ads_sasl_spnego_bind)
>> kinit succeeded but ads_sasl_spnego_gensec_bind(KRB5)
>> failed: The request is not supported.
>> [2016/11/17 16:24:45.262868, 1]
>> ../source3/winbindd/winbindd_ads.c:136(ads_cached_connection_connect)
>> ads_connect for domain DOMAINB failed: The request is not
>> supported.
>> [2016/11/17 16:24:45.262996, 3]
>> ../source3/winbindd/winbindd_ads.c:1488(sequence_number)
>> ads: fetch sequence_number for DOMAINB
>> [2016/11/17 16:24:45.263932, 3]
>> ../source3/libsmb/namequery.c:3117(get_dc_list)
>> get_dc_list: preferred server list:
>> "DS1.domainb.mydomain.com, *"
>> [2016/11/17 16:24:45.265508, 3]
>> ../source3/libads/ldap.c:618(ads_connect)
>> Successfully contacted LDAP server 192.168.x.x
>> [2016/11/17 16:24:45.265657, 3]
>> ../source3/libsmb/namequery.c:3117(get_dc_list)
>> get_dc_list: preferred server list:
>> "DS1.domainb.mydomain.com, *"
>> [2016/11/17 16:24:45.266972, 3]
>> ../source3/libads/ldap.c:618(ads_connect)
>> Successfully contacted LDAP server 192.168.x.x
>> [2016/11/17 16:24:45.268199, 3]
>> ../source3/libads/ldap.c:618(ads_connect)
>> Successfully contacted LDAP server 192.168.x.x
>> [2016/11/17 16:24:45.268892, 3]
>> ../source3/libads/ldap.c:661(ads_connect)
>> Connected to LDAP server DS1.domainb.mydomain.com
>> [2016/11/17 16:24:45.270958, 3]
>> ../source3/libads/sasl.c:733(ads_sasl_spnego_bind)
>> ads_sasl_spnego_bind: got OID=1.3.6.1.4.1.311.2.2.30
>> [2016/11/17 16:24:45.271020, 3]
>> ../source3/libads/sasl.c:733(ads_sasl_spnego_bind)
>> ads_sasl_spnego_bind: got OID=1.2.840.48018.1.2.2
>> [2016/11/17 16:24:45.271062, 3]
>> ../source3/libads/sasl.c:733(ads_sasl_spnego_bind)
>> ads_sasl_spnego_bind: got OID=1.2.840.113554.1.2.2
>> [2016/11/17 16:24:45.271102, 3]
>> ../source3/libads/sasl.c:733(ads_sasl_spnego_bind)
>> ads_sasl_spnego_bind: got OID=1.2.840.113554.1.2.2.3
>> [2016/11/17 16:24:45.271143, 3]
>> ../source3/libads/sasl.c:733(ads_sasl_spnego_bind)
>> ads_sasl_spnego_bind: got OID=1.3.6.1.4.1.311.2.2.10
>> [2016/11/17 16:24:45.610705, 0]
>> ../source3/libads/sasl.c:336(ads_sasl_spnego_gensec_bind)
>> ads_setup_sasl_wrapping() failed: The request is not supported.
>> [2016/11/17 16:24:45.617251, 0]
>> ../source3/libads/sasl.c:779(ads_sasl_spnego_bind)
>> kinit succeeded but ads_sasl_spnego_gensec_bind(KRB5)
>> failed: The request is not supported.
>> [2016/11/17 16:24:45.623138, 1]
>> ../source3/winbindd/winbindd_ads.c:136(ads_cached_connection_connect)
>> ads_connect for domain DOMAINB failed: The request is not
>> supported.
>>
>>
>>
>>
>> # /usr/local/samba/sbin/smbd -b
>>
>>
>> ...
>> --with Options:
>> WITH_ADS
>> WITH_AUTOMOUNT
>> WITH_AVAHI_SUPPORT
>> WITH_DNS_UPDATES
>> WITH_PAM
>> WITH_PAM_MODULES
>> WITH_PTHREADPOOL
>> WITH_QUOTAS
>> WITH_SYSLOG
>> WITH_WINBIND
>>
>> ...
>>
>>
>>
>> Active Directory Domains and Trusts on the DOMAINB directory server
>> shows the trusts are valid in both directions.
>>
>>
>>
>> Appreciate any advice.
>>
>>
>> On 11/14/16 12:09, Gaiseric Vandal wrote:
>>>
>>> I have a samba classic domain, called it "DomainA." All domain
>>> controllers and servers are running 3.6.25 on Solaris 11.
>>>
>>>
>>> The PDC and BDC use an LDAP backend for unix, samba and idmap
>>> data. Member servers use LDAP backend for unix accounts, so
>>> the underlying unix and group accounts are consistent.
>>>
>>> There is a trust relationship with Windows 2008 AD domain ("DomainB.")
>>>
>>>
>>>
>>> On the member servers, "wbinfo -u" and "wbinfo -g" only shows
>>> members from servers' own domain (DomainA.)
>>>
>>>
>>> The wbinfo command does indicate that domains are trusted.
>>>
>>>
>>> root at member1# wbinfo -m
>>> BUILTIN
>>> MEMBER1
>>> DOMAINA
>>> DOMAINB
>>> root at member1# wbinfo -D DOMAINB
>>> Name : DOMAINB
>>> Alt_Name : domainb.mydomain.com
>>> SID : S-1-5-21-xxxxxxxxxxxxxxx
>>> Active Directory : Yes
>>> Native : Yes
>>> Primary : No
>>> root at member1#
>>>
>>>
>>> Although I am assuming that wbinfo is merely querying the domainA
>>> PDC or BDC. The PDC is also the WINS server.
>>>
>>>
>>> I have trying to configure idmapping for domainB on the member
>>> servers, using an LDAP backend, to keep the idmapping consistent
>>> across all servers. However, I figure idmapping won't come into
>>> play if winbind is not even seeing the domainB users. I am
>>> actually unclear if the member server is supposed to contact its own
>>> domain controller for trusted account information or if it is
>>> supposed to contact the trusted domain (domainB) AD controller.
>>>
>>>
>>> The nmblookup command indicates WINS resolution is working correctly.
>>>
>>>
>>>
>>> root at member1# nmblookup -U name_of_wins_server -R 'DOMAINB#1C'
>>> …
>>> answers: nmb_name=DOMAINB<1c> rr_type=32 rr_class=1 ttl=216591
>>> answers 0 char ...... hex E000C0A8031A
>>> Got a positive name query response from ...
>>> ip_of_DomainB_AD DomainB<1c>
>>> root at member1#
>>>
>>>
>>> The log.wb-DOMAINB log shows the server locating the domain
>>> controller for the trusted domain.
>>>
>>>
>>>
>>> root at member1#testparm -v | grep winbind
>>> ....
>>> Server role: ROLE_DOMAIN_MEMBER
>>> Press enter to see a dump of your service definitions
>>>
>>> winbind separator = \
>>> winbind cache time = 300
>>> winbind reconnect delay = 30
>>> winbind max clients = 200
>>> winbind enum users = Yes
>>> winbind enum groups = Yes
>>> winbind use default domain = No
>>> winbind trusted domains only = No
>>> winbind nested groups = Yes
>>> winbind expand groups = 1
>>> winbind nss info = template
>>> winbind refresh tickets = No
>>> winbind offline logon = No
>>> winbind normalize names = No
>>> winbind rpc only = No
>>> winbind max domain connections = 1
>>>
>>> root at member1#
>>>
>>>
>>>
>>>
>>> The IDMAP entry in smb.conf is as follows
>>>
>>> idmap config DOMAINB:backend = ldap
>>> # idmap config DOMAINB:readonly = no
>>> idmap config DOMAINB:readonly = yes
>>> idmap config DOMAINB:default=no
>>> idmap config DOMAINB:ldap_base_dn =
>>> ou=domainb,ou=idmap,o=mydomain.com
>>> idmap config DOMAINB:ldap_user_dn = cn=SomeLDAPAdminUser
>>> idmap config DOMAINB:ldap_url = ldap://pdc.mydomain.com
>>> idmap config DOMAINB:range = 30000-39999
>>> #is following legit?
>>> idmap config DOMAINB:suffix=ou=domainb,ou=idmap
>>>
>>>
>>>
>>> Idmapping is required so that "getent passwd" and "getent group" can
>>> list windows users. But even if idmapping is not setup correctly, I
>>> should still see trusted users with "wbinfo -u" and "wbinfo -g."
>>>
>>>
>>> Appreciate any feedback
>>>
>>> Thanks
>>>
>>>
>>>
>>>
>>
>
More information about the samba
mailing list