Bug 1540457
| Summary: | User login issue from one-way trusted domains has not been fixed | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | vincent.wang |
| Component: | samba | Assignee: | Andreas Schneider <asn> |
| Status: | CLOSED ERRATA | QA Contact: | Andrej Dzilský <adzilsky> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.5 | CC: | adzilsky, amitkuma, arajendr, asn, gdeschner, jarrpa, rhack, vincentwang1208 |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | samba-4.8.2-2.el7 | Doc Type: | Enhancement |
| Doc Text: |
For a long time winbind was not able to authenticate users from trusted domain which only had a one way trust. Samba has been developed for NT4-style domain controllers first. The way it worked was fine for NT4 but AD works completely different so we needed to remove the assumptions winbind had about AD. This took a long time because a lot of code needed to be refactored.
Finally authentication from users of one way trusts is working the the following ID mapping modules: idmap_rid and idmap_autorid.
Trusts can be evaluated using the following command:
'wbinfo --trusted-domains --verbose'
Winbind changes
---------------
The dependency to global list of trusted domains within
the winbindd processes has been reduced a lot.
The construction of that global list is not reliable and often
incomplete in complex trust setups. In most situations the list is not needed
any more for winbindd to operate correctly. E.g. for plain file serving via SMB
using a simple idmap setup with autorid, tdb or ad. However some more complex
setups require the list, e.g. if you specify idmap backends for specific
domains. Some pam_winbind setups may also require the global list.
If you have a setup that doesn't require the global list, you should set
"winbind scan trusted domains = no".
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-10-30 07:59:53 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1420851 | ||
|
Description
vincent.wang
2018-01-31 05:51:13 UTC
Can you please draw a map of you forest and trusts? Also is that transitive trust one way or two way trust? Can you also provide logs of the fail? https://www.samba.org/~asn/reporting_samba_bugs.txt Domain trust and relationships:
/\ /\
/ \ / \
/ \ / \
/ \ / \
/ \ One way cross forest transitive trust / \
/ \ <----------------------------------------- / \
/CUSTOMER.COM\ /MYDOMAIN.COM\
/______________\ /______________\
\ \ |
\ \ |
\ \ |
\ \ +-----------------------+
/\ /\ | Linux Servers joined |
/ \ / \ | to the above domain |
/SYD \ /ACT \ +-----------------------+
/______\ /______\
1. Users from MYDOMAIN.COM login onto the Linux server always successful
2. Users from CUSTOMER.COM and its sub-domains (SYD,ACT) cannot login onto the Linux servers which are joined to MYDOMAIN.COM
I'll extract the Winbind log and attache it.
I'm sorry but one way trusts are not working with Samba yet. There are some improvements in Samba 4.7 (install RHEL 7.5 Beta for testing) more in Samba 4.8, but it is still not fully fixed. I think we will get there with Samba 4.9. The upstream bug is: https://bugzilla.samba.org/show_bug.cgi?id=8630 Work in Progress: https://git.samba.org/?p=slow/samba.git;a=shortlog;h=refs/heads/trusts-ok Hi Has tested this on RHEL7.5 Beta, still fails. But thanks for your updates, I totally understand the challenging interacting with MS' AD. I'll keep watching the progress of the improvements. One of customer have this Query: Is the patch going to be available for RHEL6 when the bug is resolved? Customer is using 6.9 No change, there are major changes to winbind to get this working correctly. *** Bug 1481113 has been marked as a duplicate of this bug. *** Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:3056 |