This bug is a high priority for IPA as without it, users would have an outage  when migrating from RHEL-6 to RHEL-7.1 and still having clients connected to RHEL-6.6 IPA master.

Upstream ticket:
https://fedorahosted.org/389/ticket/47825

Hi Martin,

The problem is in RHEL-6.x (389-ds-base-1.2.11.X) or RHEL-7.0 (389-ds-base-1.3.1.X)?

It'd affect the target flag of this bug...
Flags: 	
mkosek: 	rhel-6.6.0 		

Thanks,
--noriko

(In reply to Noriko Hosoi from comment #3)
> Hi Martin,
> 
> The problem is in RHEL-6.x (389-ds-base-1.2.11.X) or RHEL-7.0
> (389-ds-base-1.3.1.X)?
> 
> It'd affect the target flag of this bug...
> Flags: 	
> mkosek: 	rhel-6.6.0 		
> 
> Thanks,
> --noriko

Never mind.  Nathan gave me a clear explanation.  We need to have this fix on all the supported version (1.2.11 and up)  And Ludwig is already working on this issue.

Was this issue found after failure of ssh?

We're discussing where to automate testing for this one.  With ssh tests?  General install tests?  Or, can it cause even more widespread issues? that could affect many different functions other than just login?

When the issue was occurring, I reproduced it with ssh tests, sudo tests and with the ldapsearch mentioned in the Description. The ldapsearch seems as the most straightforward test to do as "ssh" test is more functional and could be broken by many others things but this particular bug. Also CCing Jakub in case he has other ideas for reproduction.

SSSD uses dereference for fetching group members in one go and for HBAC. So anything that exercises HBAC (any login with a PAM service pretty much) should test the dereference code.

Ok, so sounds like this one affects a lot.

I think I'm missing something though for how to reproduce this.  I tried installing older version of ipa and 389-ds-base:

ipa-server-3.0.0-41.el6.x86_64
389-ds-base-1.2.11.15-36.el6.x86_64

But when I try to lookup the master, I'm seeing expected, not failure (I think):

ldapsearch -Y GSSAPI -h $MASTER  -b "fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test" -E 'deref=managedBy:objectclass'
...
dn: fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,
 dc=test
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEOMIQAAAEIBAltYW5hZ2VkQnkEUWZxZ
 G49bWFzdGVyLmlwYTEuZXhhbXBsZS50ZXN0LGNuPWNvbXB1dGVycyxjbj1hY2NvdW50cyxkYz1pcG
 ExLGRjPWV4YW1wbGUsZGM9dGVzdKCEAAAApDCEAAAAngQLb2JqZWN0Y2xhc3MxhAAAAIsEA3RvcAQ
 JaXBhb2JqZWN0BAZuc2hvc3QEB2lwYWhvc3QECmlwYXNlcnZpY2UEB3BraXVzZXIED2tyYnByaW5j
 aXBhbGF1eAQMa3JicHJpbmNpcGFsBBJrcmJ0aWNrZXRwb2xpY3lhdXgECmlwYXNzaGhvc3QEFGlwY
 VNzaEdyb3VwT2ZQdWJLZXlz
# managedBy: <objectclass=top>;<objectclass=ipaobject>;<objectclass=nshost>;<
 objectclass=ipahost>;<objectclass=ipaservice>;<objectclass=pkiuser>;<objectc
 lass=krbprincipalaux>;<objectclass=krbprincipal>;<objectclass=krbticketpolic
 yaux>;<objectclass=ipasshhost>;<objectclass=ipaSshGroupOfPubKeys>;fqdn=maste
 r.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test

I even tried installing a separate client in case this didn't affect master:

dn: fqdn=client1.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example
 ,dc=test
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEKMIQAAAEEBAltYW5hZ2VkQnkEUmZxZ
 G49Y2xpZW50MS5pcGExLmV4YW1wbGUudGVzdCxjbj1jb21wdXRlcnMsY249YWNjb3VudHMsZGM9aX
 BhMSxkYz1leGFtcGxlLGRjPXRlc3SghAAAAJ8whAAAAJkEC29iamVjdGNsYXNzMYQAAACGBAlpcGF
 vYmplY3QEBm5zaG9zdAQHaXBhaG9zdAQHcGtpdXNlcgQKaXBhc2VydmljZQQPa3JicHJpbmNpcGFs
 YXV4BAxrcmJwcmluY2lwYWwEDWllZWU4MDJkZXZpY2UECmlwYXNzaGhvc3QEA3RvcAQUaXBhU3NoR
 3JvdXBPZlB1YktleXM=
# managedBy: <objectclass=ipaobject>;<objectclass=nshost>;<objectclass=ipahos
 t>;<objectclass=pkiuser>;<objectclass=ipaservice>;<objectclass=krbprincipala
 ux>;<objectclass=krbprincipal>;<objectclass=ieee802device>;<objectclass=ipas
 shhost>;<objectclass=top>;<objectclass=ipaSshGroupOfPubKeys>;fqdn=client1.ip
 a1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test

Is there something else I need to do in order for the ldapsearch to show the failure?

the problem became only visible in recent version of IPA where new acis were introduced.
The problem is triggered if access to the managedby attribute is granted by an aci containing a targetfilter rule

How can I confirm those acis are or aren't in place?  And, can I manually add one to test with?

Should I be able to add the aci with ipa permission-add command?  Do we have an example I could use for that?

Thanks,
Scott

No, this depends on a permission/ACI refactoring done in FreeIPA 4.0 (http://www.freeipa.org/page/V4/Permissions_V2). I think the easiest way is to:

1) Install RHEL-6.6 IPA server
2) Install FreeIPA 4.0 replica (http://www.freeipa.org/page/Releases/4.0.0)
3) Test that the deref LDAP works or do functional tests as advised in Comment 7 and Comment 8

Alternatively, you could verify this as sanity only and only verify that current deref LDAP searches are not broken.

Ok, great.  I've been able to reproduce with RHEL 6.5 master and Fedora 20 replica running freeipa 4.0.1.

With 389-ds-base-1.2.11.15-29.el6.x86_64:

[root@rhel6-1 ~]# ldapsearch -Y GSSAPI -h $MASTER  -b "fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test" -E 'deref=managedBy:objectclass'
SASL/GSSAPI authentication started
SASL username: host/master.ipa1.example.test.TEST
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
# with dereference control
#

# master.ipa1.example.test, computers, accounts, ipa1.example.test
dn: fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,
 dc=test
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAABkMIQAAABeBAltYW5hZ2VkQnkEUWZxZ
 G49bWFzdGVyLmlwYTEuZXhhbXBsZS50ZXN0LGNuPWNvbXB1dGVycyxjbj1hY2NvdW50cyxkYz1pcG
 ExLGRjPWV4YW1wbGUsZGM9dGVzdA==
# managedBy: fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,d
 c=example,dc=test

So, I'll update and verify. 

Thanks for the help here.

Verified.

Version ::

389-ds-base-1.2.11.15-38.el6.x86_64

Results ::

[root@rhel6-1 ~]# yum update 389-ds-base
Loaded plugins: product-id, security, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package 389-ds-base.x86_64 0:1.2.11.15-29.el6 will be updated
---> Package 389-ds-base.x86_64 0:1.2.11.15-38.el6 will be an update
--> Processing Dependency: 389-ds-base-libs = 1.2.11.15-38.el6 for package: 389-ds-base-1.2.11.15-38.el6.x86_64
--> Running transaction check
---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-29.el6 will be updated
---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-38.el6 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================================
 Package                Arch         Version                 Repository                           Size
=======================================================================================================
Updating:
 389-ds-base            x86_64       1.2.11.15-38.el6        beaker-rhel-6.6-latest-server       1.5 M
Updating for dependencies:
 389-ds-base-libs       x86_64       1.2.11.15-38.el6        beaker-rhel-6.6-latest-server       414 k

Transaction Summary
=======================================================================================================
Upgrade       2 Package(s)

Total download size: 1.9 M
Is this ok [y/N]: y
Downloading Packages:
(1/2): 389-ds-base-1.2.11.15-38.el6.x86_64.rpm                                  | 1.5 MB     00:01     
(2/2): 389-ds-base-libs-1.2.11.15-38.el6.x86_64.rpm                             | 414 kB     00:00     
-------------------------------------------------------------------------------------------------------
Total                                                                  545 kB/s | 1.9 MB     00:03     
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating   : 389-ds-base-libs-1.2.11.15-38.el6.x86_64                                            1/4 
  Updating   : 389-ds-base-1.2.11.15-38.el6.x86_64                                                 2/4 
  Cleanup    : 389-ds-base-1.2.11.15-29.el6.x86_64                                                 3/4 
  Cleanup    : 389-ds-base-libs-1.2.11.15-29.el6.x86_64                                            4/4 
beaker-rhel-6.6-latest-server/productid                                         | 1.6 kB     00:00     
beaker-rhel65-server/productid                                                  | 1.7 kB     00:00     
  Verifying  : 389-ds-base-libs-1.2.11.15-38.el6.x86_64                                            1/4 
  Verifying  : 389-ds-base-1.2.11.15-38.el6.x86_64                                                 2/4 
  Verifying  : 389-ds-base-1.2.11.15-29.el6.x86_64                                                 3/4 
  Verifying  : 389-ds-base-libs-1.2.11.15-29.el6.x86_64                                            4/4 

Updated:
  389-ds-base.x86_64 0:1.2.11.15-38.el6                                                                

Dependency Updated:
  389-ds-base-libs.x86_64 0:1.2.11.15-38.el6                                                           

Complete!
[root@rhel6-1 ~]# ipactl restart
Restarting Directory Service
Shutting down dirsrv: 
    IPA1-EXAMPLE-TEST...                                   [  OK  ]
    PKI-IPA...                                             [  OK  ]
Starting dirsrv: 
    IPA1-EXAMPLE-TEST...                                   [  OK  ]
    PKI-IPA...                                             [  OK  ]
Restarting KDC Service
Stopping Kerberos 5 KDC:                                   [  OK  ]
Starting Kerberos 5 KDC:                                   [  OK  ]
Restarting KPASSWD Service
Stopping Kerberos 5 Admin Server:                          [  OK  ]
Starting Kerberos 5 Admin Server:                          [  OK  ]
Restarting DNS Service
Stopping named: .                                          [  OK  ]
Starting named:                                            [  OK  ]
Restarting MEMCACHE Service
Stopping ipa_memcached:                                    [  OK  ]
Starting ipa_memcached:                                    [  OK  ]
Restarting HTTP Service
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [  OK  ]
Restarting CA Service
Stopping pki-ca:                                           [  OK  ]
Starting pki-ca:                                           [  OK  ]
[root@rhel6-1 ~]# ldapsearch -Y GSSAPI -h $MASTER  -b "fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test" -E 'deref=managedBy:objectclass'
SASL/GSSAPI authentication started
SASL username: host/master.ipa1.example.test.TEST
SASL SSF: 56
SASL data security layer installed.
# extended LDIF
#
# LDAPv3
# base <fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
# with dereference control
#

# master.ipa1.example.test, computers, accounts, ipa1.example.test
dn: fqdn=master.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,
 dc=test
control: 1.3.6.1.4.1.4203.666.5.16 false MIQAAAEOMIQAAAEIBAltYW5hZ2VkQnkEUWZxZ
 G49bWFzdGVyLmlwYTEuZXhhbXBsZS50ZXN0LGNuPWNvbXB1dGVycyxjbj1hY2NvdW50cyxkYz1pcG
 ExLGRjPWV4YW1wbGUsZGM9dGVzdKCEAAAApDCEAAAAngQLb2JqZWN0Y2xhc3MxhAAAAIsEA3RvcAQ
 JaXBhb2JqZWN0BAZuc2hvc3QEB2lwYWhvc3QECmlwYXNlcnZpY2UEB3BraXVzZXIED2tyYnByaW5j
 aXBhbGF1eAQMa3JicHJpbmNpcGFsBBJrcmJ0aWNrZXRwb2xpY3lhdXgECmlwYXNzaGhvc3QEFGlwY
 VNzaEdyb3VwT2ZQdWJLZXlz
# managedBy: <objectclass=top>;<objectclass=ipaobject>;<objectclass=nshost>;<
 objectclass=ipahost>;<objectclass=ipaservice>;<objectclass=pkiuser>;<objectc
 lass=krbprincipalaux>;<objectclass=krbprincipal>;<objectclass=krbticketpolic
 yaux>;<objectclass=ipasshhost>;<objectclass=ipaSshGroupOfPubKeys>;fqdn=maste
 r.ipa1.example.test,cn=computers,cn=accounts,dc=ipa1,dc=example,dc=test

Unfortunately, SSSD team discovered that current deref fixes are not sufficient and SSSD will fail to enumerate groups with users having a special IPA RBAC role assigned.

The root cause of the issue is that user contains some memberOf attributes to entries which are not visible to SSSD and DS returns incomplete results in the deref call. This problem makes SSSD to fail in resolving such user groups.

We plan to solve this issue both on server side - in 389-ds-base component, i.e. this bug. Upstream tracks the problem in ticket
https://fedorahosted.org/389/ticket/47885
This should be done for RHEL-6.6 as it is already a minimal IPA server version to use when RHEL-7.1 replica is being added due to this Bugzilla.

Second part is a fix on SSSD client to be more robust in the deref call and fall back properly - tracked in Bug 1135432 targeted on later RHEL release.

Moving this bug back to ASSIGNED so that we can add the additional fix so that RHEL clients can work with RHEL-6.6 servers replicating with RHEL-7.1 servers.

Looks like newer build has come for 389-ds-base. I am not sure whether the same can be verified by DS QE team... Can this fix be verified by SSSD team?

(In reply to Sankar Ramalingam from comment #23)
> Looks like newer build has come for 389-ds-base. I am not sure whether the
> same can be verified by DS QE team... Can this fix be verified by SSSD team?

This fix for the ticket 47885 can be verified just on the directory server.

Ludwig, could you please put the steps to verify?  Thanks!!

steps to verify

0. enabel deref and memberof plugin (use member as memberof attr)
1. create a suffix dc=example,dc=com
2. remove all acis
3, create a public and privaet subtree:

dn: ou=public,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: public
aci: (targetattr!="userPassword")(version 3.0; acl "Anonymous access"; allow (read,search,compare) userdn="ldap:///anyone";)

dn: ou=private,dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: private

4. add a public and private group

dn: cn=g1,ou=private,dc=example,dc=com
objectClass: groupofnames
objectClass: top
member: uid=user.9999,ou=People,dc=example,dc=com
cn: g1

dn: cn=g1,ou=public,dc=example,dc=com
member: uid=user.9999,ou=People,dc=example,dc=com
objectClass: groupofnames
objectClass: top
cn: g1

5. do search with deref control as dirctory manager, you will get both groups:
ldapsearch .....-D "cn=directory manager" -w  ... -b "dc=example,dc=com" "uid=user.9999" -E "deref=memberof:objectclass" memberof

dn: uid=user.9999,ou=People,dc=example,dc=com
# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=private,dc=example,dc=com

# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=public,dc=example,dc=com

memberof: cn=g1,ou=private,dc=example,dc=com
memberof: cn=g1,ou=public,dc=example,dc=com


6. do the same search as an ordinary user, it should only deref the public group:

ldapsearch -LLL -o ldif-wrap=no -x -h localhost -p 30522 -D "uid=user.9998,ou=People,dc=example,dc=com" -w password -b "dc=example,dc=com" "uid=user.9999" -E "deref=memberof:objectclass" memberof

dn: uid=user.9999,ou=People,dc=example,dc=com
# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=public,dc=example,dc=com

memberof: cn=g1,ou=private,dc=example,dc=com
memberof: cn=g1,ou=public,dc=example,dc=com

Created ou, groups and users as given in comment #25. But, there are few modifications to be done to get the exact result.

Step 0: use memberof as memberof attr in memberOf plug-in. Not member as memberof attr.


Before doing step4, you need to create user.9999

dn: uid=user.9999,ou=public,dc=example3,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

Step 4: use public instead of people for member attr in private and public groups.

dn: cn=g1,ou=private,dc=example,dc=com
objectClass: groupofnames
objectClass: top
member: uid=user.9999,ou=public,dc=example,dc=com
cn: g1

dn: cn=g1,ou=public,dc=example,dc=com
member: uid=user.9999,ou=public,dc=example,dc=com
objectClass: groupofnames
objectClass: top
cn: g1

Step 5: ldapsearch -x -p 1289 -h localhost -D "cn=Directory Manager" -w Secret123 -b "dc=example,dc=com" "uid=user.9999" -E "deref=memberof:objectclass" "# memberof:"

Result:
# 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 MIQAAADNMIQAAABhBAhtZW1iZXJvZgQjY249Z
 zEsb3U9cHJpdmF0ZSxkYz1leGFtcGxlMyxkYz1jb22ghAAAACwwhAAAACYEC29iamVjdGNsYXNzMY
 QAAAATBAxncm91cG9mbmFtZXMEA3RvcDCEAAAAYAQIbWVtYmVyb2YEImNuPWcxLG91PXB1YmxpYyx
 kYz1leGFtcGxlMyxkYz1jb22ghAAAACwwhAAAACYEC29iamVjdGNsYXNzMYQAAAATBAxncm91cG9m
 bmFtZXMEA3RvcA==
# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=private,dc=
 example,dc=com

# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=public,dc=e
 xample,dc=com


Step 6: Add user.9993 to ou=public as user.9999.

Run ldapsearch as user.9993
ldapsearch -x -p 1289 -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" "deref=memberof:objectclass" "# memberof:"

Result:
# 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 MIQAAABmMIQAAABgBAhtZW1iZXJvZgQiY249Z
 zEsb3U9cHVibGljLGRjPWV4YW1wbGUzLGRjPWNvbaCEAAAALDCEAAAAJgQLb2JqZWN0Y2xhc3MxhA
 AAABMEDGdyb3Vwb2ZuYW1lcwQDdG9w
# memberof: <objectclass=groupofnames>;<objectclass=top>;cn=g1,ou=public,dc=e
 xample,dc=com


Ldapsearch as normal user with deref control produces results only with public groups. Hence, marking the bug as verified.

can I know the reason why it has been changed to POST? Is there anything changing from what I posted in the verification steps?

(In reply to Sankar Ramalingam from comment #27)
> can I know the reason why it has been changed to POST? Is there anything
> changing from what I posted in the verification steps?

Because of a regression by the ticket 47885, another build is coming including the fix.

This final verification can be done by IPA, I think.

Please see also https://bugzilla.redhat.com/show_bug.cgi?id=1139361
Bug 1139361 - RHEL6.6 ssh as admin on ipa server fails after 389-ds-base update

Reopening due to regressions encountered (described in bug 1139361).

*** Bug 1139361 has been marked as a duplicate of this bug. ***

This version seems to fix my issue from bug #1139361 for ssh as admin:

[root@rhel6-1 ~]# rpm -q 389-ds-base
389-ds-base-1.2.11.15-43.el6.x86_64
[root@rhel6-1 ~]# ssh admin@$(hostname)
admin.test's password: 
Connection closed by UNKNOWN

After upgade to release -45, it works:

[root@rhel6-1 yum.local.d]# yum update 389-ds-base
Loaded plugins: product-id, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
Setting up Update Process
mylocal                                                                         | 2.9 kB     00:00 ... 
mylocal/primary_db                                                              |  36 kB     00:00 ... 
Resolving Dependencies
--> Running transaction check
---> Package 389-ds-base.x86_64 0:1.2.11.15-44.el6 will be updated
---> Package 389-ds-base.x86_64 0:1.2.11.15-45.el6 will be an update
--> Processing Dependency: 389-ds-base-libs = 1.2.11.15-45.el6 for package: 389-ds-base-1.2.11.15-45.el6.x86_64
--> Running transaction check
---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-44.el6 will be updated
---> Package 389-ds-base-libs.x86_64 0:1.2.11.15-45.el6 will be an update
--> Finished Dependency Resolution

Dependencies Resolved

=======================================================================================================
 Package                     Arch              Version                        Repository          Size
=======================================================================================================
Updating:
 389-ds-base                 x86_64            1.2.11.15-45.el6               mylocal            1.5 M
Updating for dependencies:
 389-ds-base-libs            x86_64            1.2.11.15-45.el6               mylocal            417 k

Transaction Summary
=======================================================================================================
Upgrade       2 Package(s)

Total download size: 1.9 M
Is this ok [y/N]: y
Downloading Packages:
-------------------------------------------------------------------------------------------------------
Total                                                                  102 MB/s | 1.9 MB     00:00     
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating   : 389-ds-base-libs-1.2.11.15-45.el6.x86_64                                            1/4 
  Updating   : 389-ds-base-1.2.11.15-45.el6.x86_64                                                 2/4 
  Cleanup    : 389-ds-base-1.2.11.15-44.el6.x86_64                                                 3/4 
  Cleanup    : 389-ds-base-libs-1.2.11.15-44.el6.x86_64                                            4/4 
  Verifying  : 389-ds-base-1.2.11.15-45.el6.x86_64                                                 1/4 
  Verifying  : 389-ds-base-libs-1.2.11.15-45.el6.x86_64                                            2/4 
  Verifying  : 389-ds-base-libs-1.2.11.15-44.el6.x86_64                                            3/4 
  Verifying  : 389-ds-base-1.2.11.15-44.el6.x86_64                                                 4/4 

Updated:
  389-ds-base.x86_64 0:1.2.11.15-45.el6                                                                

Dependency Updated:
  389-ds-base-libs.x86_64 0:1.2.11.15-45.el6                                                           

Complete!

[root@rhel6-1 yum.local.d]# ipactl restart
Restarting Directory Service
Shutting down dirsrv: 
    PKI-IPA...                                             [  OK  ]
    TESTRELM-TEST...                                       [  OK  ]
Starting dirsrv: 
    PKI-IPA...                                             [  OK  ]
    TESTRELM-TEST...                                       [  OK  ]
Restarting KDC Service
Stopping Kerberos 5 KDC:                                   [  OK  ]
Starting Kerberos 5 KDC:                                   [  OK  ]
Restarting KPASSWD Service
Stopping Kerberos 5 Admin Server:                          [  OK  ]
Starting Kerberos 5 Admin Server:                          [  OK  ]
Restarting DNS Service
Stopping named: .                                          [  OK  ]
Starting named:                                            [  OK  ]
Restarting MEMCACHE Service
Stopping ipa_memcached:                                    [  OK  ]
Starting ipa_memcached:                                    [  OK  ]
Restarting HTTP Service
Stopping httpd:                                            [  OK  ]
Starting httpd:                                            [  OK  ]
Restarting CA Service
Stopping pki-ca:                                           [  OK  ]
Starting pki-ca:                                           [  OK  ]

[root@rhel6-1 yum.local.d]# ssh admin@$(hostname)
admin.test's password: 
Last login: Tue Sep  9 08:10:00 2014 from rhel6-1.testrelm.test
Could not chdir to home directory /home/admin: No such file or directory

-bash-4.1$ exit
logout

I'm still running other tests but, that issue does seem to be resolved.

Thank you!

Changing the status to ON_QA as per Noriko's comment #30.

Based on comment #32, marking the bug as Verified. Thanks Scott!

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.

http://rhn.redhat.com/errata/RHBA-2014-1385.html