Good afternoon all. I'm looking for some help on something that I've
been
bashing my head against a wall now for quite some time.
The goal is this: a CentOS system joined to an AD domain should allow users
of a trusted domain to authenticate and login.
* I have a CentOS system ("BLUE") joined to domain BAR. Easy and
done,
and users in the BAR domain can log into BLUE just fine.
* AD domain BAR has a one-way trust with domain FOO; BAR trusts FOO, but
FOO does not trust BAR. My AD guy has that taken care of, and cross-domain
login works fine on Windows systems. 2-way trust is not an option.
Organizationally, FOO is a super-domain where our admins live. BAR (and
BAZ and QUX and so on) are normal domains where non-admin users and
computers live.
Users in FOO need to be able to log into BLUE, but they cannot. This is
where I've been bashing my skull for some time.
BLUE is CentOS7, joined to BAR via the "realm join" command, so
/etc/krb5.conf is empty-as-distributed, not configured-for-BAR. This is a
lab environment.
=== smb.conf [global] section
=========================================================================log
level = 10
debug pid = true
max log size = 0
workgroup = BAR
security = ads
passdb backend = tdbsam
printing = cups
printcap name = cups
load printers = yes
cups options = raw
kerberos method = system keytab
template homedir = /home/%D/%U
template shell = /bin/bash
realm = BAR.DEV
winbind use default domain = no
winbind refresh tickets = yes
winbind offline logon = yes
winbind enum groups = no
winbind enum users = no
winbind separator = +
idmap config * : backend = rid
idmap config * : range = 200000-299999
idmap config * : rangesize = 10000
idmap config FOO : backend = rid
idmap config FOO : range = 100000-199999
idmap config FOO : rangesize = 10000
password server = bar.dev
allow trusted domains = yes
ldap connection timeout = 10
ldap timeout = 30
winbind max domain connections = 10
=======================================================================================================
As should be somewhat obvious, we're not stashing uids in AD, we're
using
RID and assigning ranges - FOO getting a specific range and everything else
getting a second range. I don't need to worry about BAZ users overlapping
QUX users because it'll never happen.
In my lab, BLUE and the DCs for FOO and BAR are all on the same subnet, so
no firewall bulls--t to deal with.
Timesync crap:
* FOO is synced externally.
* BAR is synced to FOO and is within a few seconds (Windows time
sloppiness)
* BLUE is synced to BAR is within a few seconds.
BLUE can resolve SRV records for these just fine:
* SRV _ldap._tcp.bar.dev
* SRV _Kerberos._tcp.bar.dev
* SRV _ldap._tcp.foo.dev
* SRV _Kerberos._tcp.foo.dev
At the moment, I'm trying to chase down why "wbinfo
--online-status" shows
FOO as offline. Browsing through /var/log/samba/log.wb-FOO at log level 10:
* At winbindd startup, there's a block of messages indicating FOO and BAR
are offline
- set_domain_online_request: called for domain FOO
- set_domain_online_request: domain FOO was globally offline.
- set_domain_online_request: called for domain BAR
- set_domain_online_request: domain BAR was globally offline.
- set_domain_online_request: called for domain FOO
- set_domain_online_request: called for domain BAR
The next block of lines seems to be winbindd failing on FOO:
- account_lockout_policy_handler called
- wcache_tdc_fetch_domain: Searching for domain FOO
- wcache_tdc_fetch_domain: Found domain FOO
- winbindd_can_contact_domain: FOO is an AD domain and we have no inbound
trust.
- account_lockout_policy_handler: Removing myself since I do not have an
incoming trust to domain FOO
- child daemon request 59
- child_process_request: request fn NDRCMD
- winbindd_dual_ndrcmd: Running command WBINT_QUERYUSERLIST (FOO)
- wbint_QueryUserList: struct wbint_QueryUserList
- in: struct wbint_QueryUserList
- connection_ok: Connection to (null) for domain FOO is not connected
After this is another block of lines about linking up to BAR which
ultimately appears to succeed.
So... what more can I paste in to give you gurus something more useful to
look at?
My take on it goes a couple of ways, neither of which seem to be fruitful
for finding a resolution:
* BLUE is trying to communicate with FOO first, but since BLUE isn't
joined to FOO, that doesn't go anywhere. I'm wondering if it did BAR
first, whether it would then be able to deal with FOO since BAR trusts FOO.
* Maybe BLUE needs to have its own trust relationship with FOO? But that
doesn't seem to be a viable path - BLUE is not, and will not be a Samba DC.
Thanks in advance,
-9
