Bug 2120572
| Summary: | ipa trust-add fails with ipa: ERROR: Insufficient access in FIPS mode | |||
|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Varun Mylaraiah <mvarun> | |
| Component: | ipa | Assignee: | Trivino <ftrivino> | |
| Status: | CLOSED MIGRATED | QA Contact: | ipa-qe <ipa-qe> | |
| Severity: | unspecified | Docs Contact: | Filip Hanzelka <fhanzelk> | |
| Priority: | unspecified | |||
| Version: | 8.7 | CC: | abokovoy, atikhono, fhanzelk, frenaud, ftrivino, pasik, pbrezina, rcritten, sbose, tscherf | |
| Target Milestone: | rc | Keywords: | MigratedToJIRA, Regression, TestBlocker, Triaged | |
| Target Release: | --- | Flags: | mvarun:
needinfo-
|
|
| Hardware: | x86_64 | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | Doc Type: | Known Issue | ||
| Doc Text: |
.IdM in FIPS mode does not support using the NTLMSSP protocol to establish a two-way cross-forest trust
Establishing a two-way cross-forest trust between Active Directory (AD) and Identity Management (IdM) with FIPS mode enabled fails because the New Technology LAN Manager Security Support Provider (NTLMSSP) authentication is not FIPS-compliant. IdM in FIPS mode does not accept the RC4 NTLM hash that the AD domain controller uses when attempting to authenticate.
|
Story Points: | --- | |
| Clone Of: | ||||
| : | 2124243 (view as bug list) | Environment: | ||
| Last Closed: | 2023-09-18 19:55:09 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: | 2089955, 2124243, 2144443, 2209172 | |||
|
Description
Varun Mylaraiah
2022-08-23 09:39:27 UTC
Hi,
> ipa: ERROR: Insufficient access: IPA master denied trust validation requests from AD DC 10 times.
Why did you change component to 'sssd'?
Alexey, we see SSSD logs a message which wasn't there in previous versions and we want you to analyze why this happens: (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [ipa_idmap_check_posix_child] (0x4000): [RID#1] Trying to add idmap for domain [S-1-5-21-2745230106-1393044594-1451765025]. (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sss_domain_get_state] (0x1000): [RID#1] Domain atmt2k12r2.test is Active (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [ipa_idmap_check_posix_child] (0x0040): [RID#1] find_domain_by_sid failed with SID [S-1-5-21-2745230106-1393044594-1451765025]. (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [ipa_idmap_get_ranges_from_sysdb] (0x0040): [RID#1] ipa_idmap_check_posix_child failed. (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): [RID#1] Could not add new domain for sid [S-1-5-21-2745230106-1393044594-1451765025] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [ipa_subdom_store] (0x0400): [RID#1] Domain mpg mode for win2012r2-fl8g.test: false (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [ldb] (0x10000): [RID#1] Added timed event "ldb_kv_callback": 0x564d23962a80 We never seen this before. SID "S-1-5-21-2745230106-1393044594-1451765025" in unknown to SSSD at this point. Is this a SID of a child domain? Sumit, could you please take a look? Hi, the behavior of SSSD is expected because there are no id-ranges for the trusted AD forest created, maybe due to the validation error. If you grep the logs for 'RID#1' you can see the whole 'Subdomains' requests which read various data from the IPA server about trusted domains and other centrally managed configuration. First the id-ranges are read (I filtered out [ldb] messages: (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_search_bases_ex_next_base] (0x0400): [RID#1] Issuing LDAP lookup with base [cn=ranges,cn=etc,dc=atmt2k12r2,dc=test] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_print_server] (0x2000): [RID#1] Searching 10.0.203.230:389 (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_get_generic_ext_step] (0x0400): [RID#1] calling ldap_search_ext with [objectclass=ipaIDRange][cn=ranges,cn=etc,dc=atmt2k12r2,dc=test]. (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_get_generic_ext_step] (0x1000): [RID#1] Requesting attrs: [objectClass] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_get_generic_ext_step] (0x1000): [RID#1] Requesting attrs: [cn] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_get_generic_ext_step] (0x1000): [RID#1] Requesting attrs: [ipaBaseID] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_get_generic_ext_step] (0x1000): [RID#1] Requesting attrs: [ipaBaseRID] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_get_generic_ext_step] (0x1000): [RID#1] Requesting attrs: [ipaSecondaryBaseRID] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_get_generic_ext_step] (0x1000): [RID#1] Requesting attrs: [ipaIDRangeSize] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_get_generic_ext_step] (0x1000): [RID#1] Requesting attrs: [ipaNTTrustedDomainSID] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_get_generic_ext_step] (0x1000): [RID#1] Requesting attrs: [ipaRangeType] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_get_generic_ext_step] (0x1000): [RID#1] Requesting attrs: [ipaAutoPrivateGroups] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_get_generic_ext_step] (0x2000): [RID#1] ldap_search_ext called, msgid = 6 (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_op_add] (0x2000): [RID#1] New operation 6 timeout 6 (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_process_message] (0x4000): [RID#1] Message type: [LDAP_RES_SEARCH_ENTRY] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_call_op_callback] (0x20000): [RID#1] Handling LDAP operation [6][server: [10.0.203.230:389] filter: [objectclass=ipaIDRange] base: [cn=ranges,cn=etc,dc=atmt2k12r2,dc=test]] took [26.926] milliseconds. (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_entry] (0x1000): [RID#1] OriginalDN: [cn=ATMT2K12R2.TEST_id_range,cn=ranges,cn=etc,dc=atmt2k12r2,dc=test]. (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_range] (0x2000): [RID#1] No sub-attributes for [objectClass] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_range] (0x2000): [RID#1] No sub-attributes for [cn] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_range] (0x2000): [RID#1] No sub-attributes for [ipaBaseID] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_range] (0x2000): [RID#1] No sub-attributes for [ipaBaseRID] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_range] (0x2000): [RID#1] No sub-attributes for [ipaSecondaryBaseRID] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_range] (0x2000): [RID#1] No sub-attributes for [ipaIDRangeSize] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_range] (0x2000): [RID#1] No sub-attributes for [ipaRangeType] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_process_message] (0x4000): [RID#1] Message type: [LDAP_RES_SEARCH_ENTRY] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_entry] (0x1000): [RID#1] OriginalDN: [cn=ATMT2K12R2.TEST_subid_range,cn=ranges,cn=etc,dc=atmt2k12r2,dc=test]. (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_range] (0x2000): [RID#1] No sub-attributes for [objectClass] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_range] (0x2000): [RID#1] No sub-attributes for [cn] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_range] (0x2000): [RID#1] No sub-attributes for [ipaBaseID] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_range] (0x2000): [RID#1] No sub-attributes for [ipaBaseRID] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_range] (0x2000): [RID#1] No sub-attributes for [ipaIDRangeSize] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_range] (0x2000): [RID#1] No sub-attributes for [ipaNTTrustedDomainSID] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_parse_range] (0x2000): [RID#1] No sub-attributes for [ipaRangeType] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_process_message] (0x4000): [RID#1] Message type: [LDAP_RES_SEARCH_RESULT] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_get_generic_op_finished] (0x0400): [RID#1] Search result: Success(0), no errmsg set (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_op_destructor] (0x2000): [RID#1] Operation 6 finished (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sdap_search_bases_ex_done] (0x0400): [RID#1] Receiving data from base [cn=ranges,cn=etc,dc=atmt2k12r2,dc=test] (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sysdb_update_ranges] (0x0400): [RID#1] Adding range [ATMT2K12R2.TEST_id_range]. (2022-08-22 14:30:17): [be[atmt2k12r2.test]] [sysdb_update_ranges] (0x0400): [RID#1] Adding range [ATMT2K12R2.TEST_subid_range]. Only the id-range and subid-range of the IPA domain are found. Later on when reading the trusted domains the trusted AD domain is found but since there is no id-range for the domain it cannot be added properly which is shown in the log snippet from the Description. HTH bye, Sumit Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. |