Bug 1989996

Hello,

customer provided github bug link - https://github.com/SSSD/sssd/issues/5025

Dear David,

Please know that we carefully considered and evaluated your request and its potential impact on our product roadmap, market demand, and overall strategy.

While we understand that addressing enhancements, bugs, and issues is critical for ensuring the quality and reliability of our product, we need to balance these priorities with our long-term goals and resource constraints. Unfortunately, we cannot address this request at this time as it does not align with our product vision and strategy, and keeping it in the backlog would be misleading and give the false impression that we will address it in the future, thus we are closing it.

Although we cannot address this specific request, we encourage anyone to collaborate and contribute to the upstream communities, as this approach enhances the flexibility, scalability, and customization of our solution while maintaining its security and stability.

We apologize for any inconvenience this may cause, and we understand that it can be frustrating when requests/expectations are not met. However, we hope that you can appreciate that we must balance our priorities with our long-term goals and resource constraints.

Please be aware that while you are welcome to open a new support case or reopen this request, we cannot guarantee that it will be addressed due to resource constraints and the prioritization of other requests.

Once again, thank you for taking the time to share feedback with us, and we look forward to continuing to work together to deliver the best possible solution, supporting in any way we can.

Thank you for understanding,

André Boscatto
Product Owner - Identity and Access Management Department

Andre,

PKI support is critical and required to many organizations, including those supporting U.S. Government agencies/contractors.

While RedHat has done well to integrate basic PKI support, bugs like these create barriers to full compliance and PKI deployment across the industry, and highlight RedHat Enterprise products lagging years to a decade behind other distros and operating systems.

I would expect that supporting STIG compliance would be a long-term goal of RedHat, and hope you would reconsider integrating the already provided fixes in a future release.
https://github.com/SSSD/sssd/issues/5025

This has been an ongoing issue for several years, and the handling of this bug exemplifies the lack of resources applied to industry required needs. Please let us know when you're personally available for a call to discuss further, together with our TAM.

Respectfully,
Karl Grindley

Hi Karl,

(In reply to Karl Grindley from comment #4)
> 
> hope you would reconsider integrating the already provided fixes
> in a future release.
> https://github.com/SSSD/sssd/issues/5025
> 

Patches for https://github.com/SSSD/sssd/issues/5025 are shipped in RHEL since sssd-2.6, i.e. RHEL8.6/9.0

But this BZ is about https://github.com/SSSD/sssd/issues/5905 that is *not* fixed upstream.

Why is the case "users have multiple hardware tokens inserted in the system at the same time" so critical for your env?

(In reply to Alexey Tikhonov from comment #5)
> Why is the case "users have multiple hardware tokens inserted in the system
> at the same time" so critical for your env?

We have certain tokens that are required for system login and for access to resources like PKI-enabled websites. And we need to simultaneously access *other* resources (not controlled by us) that require a *different* token (not controlled by us).

I'm sorry this is not a convenient answer for Red Hat, but we need to get to work on a solution here.

Hi Karl/David,

Thank you for your feedback and for reopening the discussion on this topic. I will include your comments in the next prioritization round and carefully consider them.

We fully agree that security is a critical aspect of our product vision, and supporting STIG compliance aligns with our long-term goals.

In the past, this request may not have been prioritized due to the availability of a potential workaround, which involved keeping a single token connected at a time. However, we acknowledge that there might be scenarios where simultaneous access to multiple devices is necessary, and our initial understanding may have been limited due to lack of information.

To better understand your specific scenario and the reasons for needing simultaneous access to these devices, we would greatly appreciate it if you could provide more details and go through the questions below. This will enable us to collaborate closely and find the best solution that meets your requirements while ensuring security. 

Some were previously explored, just in case there is anything to add, otherwise feel free to skip.

1 - Can you provide specific examples of situations where simultaneous access to multiple devices is required?
2 - What are the specific tasks or activities that users need to perform when accessing multiple devices simultaneously?
3 - Are there any time-sensitive or critical operations that necessitate simultaneous access to ensure efficient workflow?
4 - How frequently does the need for simultaneous access to multiple devices arise?
5 - Are there any constraints or limitations in the current workflow that prevent users from achieving their goals without simultaneous access?
6 - What are the potential risks or negative impacts if simultaneous access is not supported or allowed? 
7 - Are there any regulatory or compliance requirements that mandate or recommend simultaneous access for certain scenarios?
8 - Are there any existing workarounds or alternative methods currently being used to address the need for simultaneous access?

Thank you for your collaboration and for helping us improve our product.

Best regards,

Andre Boscatto
Product Owner - Identity and Access Management Department

Hi Karl/David,

I wanted to follow up on the questions I shared earlier regarding the need for simultaneous access to multiple devices. Have you had an opportunity to review and discuss them internally? They will help us better understand your requirements and design an appropriate solution.

Once we have it, we can reconsider our previous decision and prioritize the necessary actions accordingly.

Thank you for your attention to this matter, and we look forward to hearing from you soon.

Best regards,

André Boscatto
Product Owner - Identity and Access Management Department

Hi Andre,


1 - Can you provide specific examples of situations where simultaneous access to multiple devices is required?

The STIG requires separate credentials depending on the action needed. Each account has specific roles and rights. STIG guidance and best practice dictates that specific actions should be escalated to that correlating account. (vs logging into and establishing a session for that privileged account and then performing actions.)

A user might escalate privileged actions using sudo, su or Polkit.

A full session would be logging in via SSH, xterm or a full X session, and having multiple sessions running at once.

In a fully STIG compliant information system, separate accounts are required for:
* Standard user account - daily use for all non-privileged actions including auth and email/document signing/encryption
* DTA account - used for transferring data from high to low, or low to high
* workstation privileged account - used for administrative actions on workstations (no privileged access on servers or domain servers)
* server privileged account - used for administrative actions on servers (no privileged access on workstations or domain servers)
* domain privileged account - used for administrative actions on domain systems (no privileged access on workstations or servers)
* other accounts deemed for specific actions by overlay STIGs or by Designated Approving Authority (DAA) or Security Controls Assessor (SCA) as required

Each account has a separate PKI token and pin assigned.  A human user could have upwards of 4 or more accounts with associated tokens.

If the system is configured for lock-on-remove of a PKI device per the STIG, then use of privilege escalation is impossible, and a full session under the provided account is required.

Otherwise, if lock-on-remove is not enabled, a user workflow would require removal of the user token, insert privileged token, perform action, remove token and reinsert user token to continue standard workflow. (email, encrypting/decrypting, etc). each time a privileged action is required. this workflow would have to be repeated for each action. Often users with privileged access on an information system could perform dozens of privileged actions per day.

In another case, it's often systems may just have more than one reader (keyboard and an onboard or USB reader). This often causes user confusion. (not knowing or finding the primary reader) SSSD selects whenever one is first, and that is the reader you must use your hardware token. We see this use case often with unclassified systems, as many these days. Although with CMMC ramping up, we expect the full above STIG to be enforced soon on unclassified.

2 - What are the specific tasks or activities that users need to perform when accessing multiple devices simultaneously?

see above.

3 - Are there any time-sensitive or critical operations that necessitate simultaneous access to ensure efficient workflow?

yes.  see above. user logging out or switching terminals and PKI is very cumbersome and not following best practices of elevating a specific action, vs an entire session. Logging in with a full session adds significant risk, also leading to orphaned/abandoned sessions running on systems.

4 - How frequently does the need for simultaneous access to multiple devices arise?

Depends on the workflow, but for a busy privileged user, could be dozens of times or more per day.

5 - Are there any constraints or limitations in the current workflow that prevent users from achieving their goals without simultaneous access?

The workflow either built to using the method above, but more commonly and worse, STIGs are disabled (such as enabling passwords instead of PKI) to not have to follow the security guidelines and policy to achieve the needed workflow. This adds significant risk to the information system.

6 - What are the potential risks or negative impacts if simultaneous access is not supported or allowed?

See #5. Lowering the security posture of the system configuration, or using full sessions are required. often linux users will revert to a windows desktop and pass credentials over ssh to avoid this issue.

7 - Are there any regulatory or compliance requirements that mandate or recommend simultaneous access for certain scenarios?
yes. see above.

8 - Are there any existing workarounds or alternative methods currently being used to address the need for simultaneous access?
with full PKI enforcement, there is no workaround other than modifying workflow or reducing security posture of the system.