Bug 1514005
| Summary: | [downstream clone - 4.1.8] ovirt-engine-extension-aaa-ldap AD integration with LDAPS fails at the Login test sequence | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | rhev-integ |
| Component: | ovirt-engine-extension-aaa-ldap | Assignee: | Ondra Machacek <omachace> |
| Status: | CLOSED ERRATA | QA Contact: | Gonza <grafuls> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | unspecified | CC: | bazulay, bugs, fjayalat, lsurette, mgoldboi, mmartinv, mperina, oourfali, pmatyas, pstehlik, Rhev-m-bugs, ykaul |
| Target Milestone: | ovirt-4.1.8 | Keywords: | Reopened, ZStream |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | 1383862 | Environment: | |
| Last Closed: | 2017-12-12 09:23:10 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Infra | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1383862 | ||
| Bug Blocks: | |||
|
Description
rhev-integ
2017-11-16 13:26:03 UTC
Created attachment 1209408 [details]
aaa-ldap-setup logs
aaa-ldap-setup logs
(Originally by Frank Jayalath)
The problem is as you can see that aaa-ldap tries to use ldaps with 389 port, but you have it enabled on 636. Srvrecord server type takes the port from the following request: dig _ldap._tcp.gc._msdcs.rhev.gsslab.bne.redhat.com SRV And it returns: win-nohauqq1iqg.rhev.gsslab.bne.redhat.com and ad-bne.rhev.gsslab.bne.redhat.com with port 389. If you would like to use ldaps with 636, I would use: pool.default.serverset.srvrecord.service = ldaps and add to your DNS ldaps SRV record with port 636. (Originally by Ondra Machacek) Hi Frank, does your aaa-ldap configuration work properly after changing DNS SRV records as suggested by Ondra? (Originally by Martin Perina) Closing as NOTABUG, feel free to reopen if information provided by Ondra in Comment 2 don't fix your issue. (Originally by Martin Perina) I would like to reopen this bug as "ovirt-engine-extension-aaa-ldap-setup" script is supposed to configure the extension in the right way. If the Windows AD has the correct DNS entries then the setup script should just work, now it doesn't because "pool.default.serverset.srvrecord.service" property is not set by the setup script to the correct value. In the other hand, Active Directory does not setup ldaps SRV DNS entries by default so I guess we need to document it somewhere or the script should warn the user once the 'ldaps' option was selected and optionally print the required SRV DNS entries. A workaround to make it work without ldaps SRV DNS entries would be changing the following properties instead pool.default.serverset.srvrecord.service': ~~~ pool.gc.serverset.single.port = 3269 pool.default.serverset.srvrecord.port= 636 ~~~ It should work in most of the cases where the Active Directory server is using the standard ports. Either way I think we need to fix this because it always fails when the user try to use 'ldaps' connections to access AD (Originally by Miguel Martin Villamuelas) OK, so let's set pool.default.serverset.srvrecord.service = ldaps when user selects ldaps. But it should be noted that ldaps is not preferred nor recommended protocol by Microsoft (that's why it not set up on AD by default) and it's recommended to use StartTLS instead. Anyway since ovirt-engine-extension-aaa-ldap 1.3.3 examples how to setup AD with LDAPS is provided, more information in [1], which is also included within aaa-ldap package. [1] https://github.com/oVirt/ovirt-engine-extension-aaa-ldap/tree/master/examples#active-directory-with-server-defined-in-dns-srv-records-using-ldaps (Originally by Martin Perina) Verified with: ovirt-engine-extension-aaa-ldap-1.3.6-1.el7ev.noarch [ INFO ] Login sequence executed successfully 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/RHBA-2017:3426 sync2jira sync2jira |