Hide Forgot
*** Bug 1112824 has been marked as a duplicate of this bug. ***
Checking whether this can be verified by IPA team?
I'm looking at this for IPA. I need some info on how this is done for RHEL7. To reproduce, do I need to test with a RHEL7 Master and Replica? I tried with a RHEL6.6 Master and RHEL7 Replica and I hit the same issues from bug #1139361 with ssh as admin: master: [root@vm-idm-057 ~]# rpm -q ipa-server 389-ds-base ipa-server-3.0.0-42.el6.x86_64 389-ds-base-1.2.11.15-48.el6_6.x86_64 replica: [root@vm-idm-041 log]# rpm -q ipa-server 389-ds-base ipa-server-4.1.0-7.el7.x86_64 389-ds-base-1.3.3.1-9.el7.x86_64 ######################################################## # [root@vm-idm-057 ~]# ssh admin@$(hostname) Connection closed by UNKNOWN And I don't see anything doing the ldapsearch from the previous verification: [root@vm-idm-057 ~]# ldapsearch -Y GSSAPI -b "fqdn=vm-idm-057.testrelm.test,cn=computers,cn=accounts,dc=testrelm,dc=test" -E 'deref=managedBy:objectclass' SASL/GSSAPI authentication started SASL username: admin@TESTRELM.TEST SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base <fqdn=vm-idm-057.testrelm.test,cn=computers,cn=accounts,dc=testrelm,dc=test> with scope subtree # filter: (objectclass=*) # requesting: ALL # with dereference control # # search result search: 4 result: 0 Success # numResponses: 1
Adding Ludwig since Noriko is on pto.
I'm seeing a lot of errors like these in the dirsrv logs: [25/Nov/2014:02:21:20 +051800] NSACLPlugin - Error: This ((targetattr = "a6record || aaaarecord || afsdbrecord || arecord || certrecord || cn || cnamerecord || dlvrecord || dnamerecord || dnsclass || dnsttl || dsrecord || hinforecord || idnsallowdynupdate || idnsallowquery || idnsallowsyncptr || idnsallowtransfer || idnsforwarders || idnsforwardpolicy || idnsname || idnssecinlinesigning || idnssoaexpire || idnssoaminimum || idnssoamname || idnssoarefresh || idnssoaretry || idnssoarname || idnssoaserial || idnsupdatepolicy || idnszoneactive || keyrecord || kxrecord || locrecord || managedby || mdrecord || minforecord || mxrecord || naptrrecord || nsec3paramrecord || nsecrecord || nsrecord || nxtrecord || ptrrecord || rrsigrecord || sigrecord || srvrecord || sshfprecord || tlsarecord || txtrecord")(target = "ldap:///idnsname=*,cn=dns,dc=testrelm,dc=test")(version 3.0;acl "permission:System: Update DNS Entries";allow (write) groupdn = "ldap:///cn=System: Update DNS Entries,cn=permissions,cn=pbac,dc=testrelm,dc=test";)) ACL will not be considered for evaluation because of syntax errors. [25/Nov/2014:02:21:20 +051800] NSACLPlugin - __aclp__init_targetattr: targetattr "ipaanchoruuid" does not exist in schema. Please add attributeTypes "ipaanchoruuid" to schema if necessary. [25/Nov/2014:02:21:20 +051800] NSACLPlugin - ACL PARSE ERR(rv=-5): (targetattr = "ipaanchoruuid [25/Nov/2014:02:21:20 +051800] NSACLPlugin - Error: This ((targetattr = "ipaanchoruuid")(target = "ldap:///cn=*,cn=compat,dc=testrelm,dc=test")(targetfilter = "(objectclass=ipaOverrideTarget)")(version 3.0;acl "permission:System: Compat Tree ID View targets";allow (compare,read,search) userdn = "ldap:///anyone";)) ACL will not be considered for evaluation because of syntax errors. Is this a problem?
don't know where you did take the acis from, but you need also have the proper schema, otherwise the acis or parts of the acis will not be loaded, and you don't know what you're testing. Why don't you use the steps provided to test with DS alone ?
teh steps are copied from: https://bugzilla.redhat.com/show_bug.cgi?id=1112702#c25
Ludwig, I was testing from the IPA perspective of mixed environment. I believe we're also looking at the DS alone test you listed. However, don't the findings there indicate a problem with installing a RHEL7.1 IPA replica with a RHEL6.6 IPA server if the schema's not being setup correctly? Do I need to file that as a separate bug against IPA? Thanks, Scott
as I said, I don't know what you did. If you have two different versions of schema then replication should align them, but I am not familiar enough with which combinations and setup procedures are supported in IPA
From DS stand point.. the verification is complete. Enabled memberOf and Deref plugin dn: cn=MemberOf Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on dn: cn=Deref Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on Restarted the dirsrv instance. Then, added a suffix called "dc=example,dc=com". Then added the following entries to the suffix. dn: dc=example,dc=com objectClass: top objectClass: domain dc: example dn: uid=user.9999,ou=Public,dc=example,dc=com telephoneNumber: 989898199 mail: user.9999@redhat.com uid: user.9999 givenName: user.9999 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: inetUser sn: user.9999 cn: user.9999 userPassword: Secret123 dn: ou=Private,dc=example,dc=com objectClass: top objectClass: organizationalunit ou: Private dn: ou=Public,dc=example,dc=com objectClass: top objectClass: organizationalunit ou: Public dn: cn=g2,ou=Private,dc=example,dc=com objectClass: groupofnames objectClass: top member: uid=user.9999,ou=Public,dc=example,dc=com cn: g2 dn: cn=g2,ou=Public,dc=example,dc=com member: uid=user.9999,ou=Public,dc=example,dc=com objectClass: groupofnames objectClass: top cn: g2 dn: uid=user.9993,ou=Public,dc=example,dc=com telephoneNumber: 989898199 mail: user.9999@redhat.com uid: user.9993 givenName: user.9993 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: inetUser sn: user.9993 cn: user.9993 userPassword: Secret123 As Directory Manager user, the ldapsearch returns memberof entries from both public and private groups. dn: uid=user.9999,ou=Public,dc=example,dc=com control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAADLMIQAAABgBAhtZW1iZXJvZgQiY249Z zIsb3U9UHJpdmF0ZSxkYz1leGFtcGxlLGRjPWNvbaCEAAAALDCEAAAAJgQLb2JqZWN0Y2xhc3MxhA AAABMEDGdyb3Vwb2ZuYW1lcwQDdG9wMIQAAABfBAhtZW1iZXJvZgQhY249ZzIsb3U9UHVibGljLGR jPWV4YW1wbGUsZGM9Y29toIQAAAAsMIQAAAAmBAtvYmplY3RjbGFzczGEAAAAEwQMZ3JvdXBvZm5h bWVzBAN0b3A= # memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g2,ou=Private,dc= example,dc=com # memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g2,ou=Public,dc=e xample,dc=com memberof: cn=g2,ou=Private,dc=example,dc=com memberof: cn=g2,ou=Public,dc=example,dc=com ------ Where as, for normal user, the ldapsearch returns only the memberof entries only from public group. Hence, marking the bug as Verified.
ldapsearch as normal user... ldapsearch -x -p 1989 -h localhost -D "uid=user.9993,ou=public,dc=example,dc=com" -w Secret123 -b "dc=example,dc=com" "uid=user.9999" -E "deref=memberof:objectclass" memberof # user.9999, Public, example.com dn: uid=user.9999,ou=Public,dc=example,dc=com control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAABlMIQAAABfBAhtZW1iZXJvZgQhY249Z zIsb3U9UHVibGljLGRjPWV4YW1wbGUsZGM9Y29toIQAAAAsMIQAAAAmBAtvYmplY3RjbGFzczGEAA AAEwQMZ3JvdXBvZm5hbWVzBAN0b3A= # memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g2,ou=Public,dc=e xample,dc=com memberof: cn=g2,ou=Private,dc=example,dc=com memberof: cn=g2,ou=Public,dc=example,dc=com
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://rhn.redhat.com/errata/RHSA-2015-0416.html