#1102 Issues authenticating after resuming from suspend while on wireless
Closed: Invalid None Opened 12 years ago by sgallagh.

https://bugzilla.redhat.com/show_bug.cgi?id=754511

Description of problem:
This issue presents itself by preventing you from unlocking the screen after
resuming from suspend.  This scenario only occurs when you were connected to a
wireless network when the laptop entered suspend mode.  When resuming, all
password attempts fail until you either restart SSSD or connect to an ethernet
connection.

Version-Release number of selected component (if applicable):
sssd-1.5.1-66.el6.x86_64
openldap-clients-2.4.23-15.el6_1.3.x86_64
openldap-2.4.23-15.el6_1.3.x86_64

How reproducible:
roughly 90% of the time

Steps to Reproduce:
1. Connect to Red Hat secure wireless network
2. Suspend your laptop
3. Leave the system suspended for at least 1 minute
4. Resume the system from suspend
5. Attempt to unlock screen

Actual results:
Failed login attempts

Expected results:
The login should revert to cached local SSSD information


Additional info:
This only seems to manifest itself right now when connecting to secure Red Hat
wireless network (with RSA token)

Fields changed

cc: => mmosesoh@redhat.com
coverity: =>
patch: => 0
rhbz: =>
tests: => 0
testsupdated: => 0
upgrade: => 0

Fields changed

description: https://bugzilla.redhat.com/show_bug.cgi?id=754511

{{{
Description of problem:
This issue presents itself by preventing you from unlocking the screen after
resuming from suspend. This scenario only occurs when you were connected to a
wireless network when the laptop entered suspend mode. When resuming, all
password attempts fail until you either restart SSSD or connect to an ethernet
connection.

Version-Release number of selected component (if applicable):
sssd-1.5.1-66.el6.x86_64
openldap-clients-2.4.23-15.el6_1.3.x86_64
openldap-2.4.23-15.el6_1.3.x86_64

How reproducible:
roughly 90% of the time

Steps to Reproduce:
1. Connect to Red Hat secure wireless network
2. Suspend your laptop
3. Leave the system suspended for at least 1 minute
4. Resume the system from suspend
5. Attempt to unlock screen

Actual results:
Failed login attempts

Expected results:
The login should revert to cached local SSSD information

Additional info:
This only seems to manifest itself right now when connecting to secure Red Hat
wireless network (with RSA token)
}}}
=> https://bugzilla.redhat.com/show_bug.cgi?id=754511

{{{
Description of problem:
This issue presents itself by preventing you from unlocking the screen after
resuming from suspend. This scenario only occurs when you were connected to a
wireless network when the laptop entered suspend mode. When resuming, all
password attempts fail until you either restart SSSD or connect to an ethernet
connection.

Version-Release number of selected component (if applicable):
sssd-1.5.1-66.el6.x86_64
openldap-clients-2.4.23-15.el6_1.3.x86_64
openldap-2.4.23-15.el6_1.3.x86_64

How reproducible:
roughly 90% of the time

Steps to Reproduce:
1. Connect to Red Hat secure wireless network
2. Suspend your laptop
3. Leave the system suspended for at least 1 minute
4. Resume the system from suspend
5. Attempt to unlock screen

Actual results:
Failed login attempts

Expected results:
The login should revert to cached local SSSD information

Additional info:
This only seems to manifest itself right now when connecting to secure Red Hat
wireless network (with RSA token)
}}}

milestone: NEEDS_TRIAGE => SSSD 1.8.0
owner: somebody => jhrozek

We have been able to reproduce this. We'll continue trying to reproduce it, but we're not going to hold up 1.8.0 for it.

blockedby: =>
blocking: =>
feature_milestone: =>
milestone: SSSD 1.8.0 (LTM) => SSSD 1.8.1 (LTM)

Steve,

I haven't been able to reproduce this since November. You should just close this out.

Ok, thanks. My original suspicion was that this might actually have been an openldap bug, not an SSSD issue. As an openldap update occurred in September, I'm inclined to believe I was correct.

Thanks!

resolution: => worksforme
status: new => closed

Replying to [comment:5 mattymo]:

Steve,

I haven't been able to reproduce this since November. You should just close this out.

One more note -- when I was trying to reproduce the bug, I ran into an SELinux issue with the exact versions of SSSD and openldap packages you described in the bugzilla. I haven't checked if the issue is still present with the latest 6.3 candidate packages, but it you changed the SELinux status from Enforcing to Permissive, that might be the reason that "fixed" the bug for you.

I'll retest and reopen the bug if I can still reproduce the SELinux denial with 6.3 packages tomorrow.

Replying to [comment:7 jhrozek]:

Replying to [comment:5 mattymo]:

Steve,

I haven't been able to reproduce this since November. You should just close this out.

One more note -- when I was trying to reproduce the bug, I ran into an SELinux issue with the exact versions of SSSD and openldap packages you described in the bugzilla. I haven't checked if the issue is still present with the latest 6.3 candidate packages, but it you changed the SELinux status from Enforcing to Permissive, that might be the reason that "fixed" the bug for you.

I'll retest and reopen the bug if I can still reproduce the SELinux denial with 6.3 packages tomorrow.

Just to put a closure here - the SELinux denial I was seeing is now being tracked by https://bugzilla.redhat.com/show_bug.cgi?id=799322

Metadata Update from @sgallagh:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.8.1 (LTM)

7 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2144

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata