*** 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
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
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
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