For a few weeks now I've been seeing a problem getting authenticated to my ipa domain. I can get command line and web UI stuff done by using the admin user but if I get a ticket using my account which is in the admins group I get the following on the web UI:
Your session has expired. Please log in again.
On the command line any ipa commands I've tried so far give me:
ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)
Getting a ticket as admin on command line lets me run ipa commands with no problem. I think I've got all pertinent certificates loaded up properly. Gonna try a reboot on one of the servers shortly. I have 4 servers on r different vlans, replication between seems to be working properly.
I think the problem is most of the user ID's we use on this domain are not in the ID range configured. We let the install choose a default range when we first set this up. Most of our users have a UID based on their EDIPI # which is a 32-bit ID assigned when a user first gets a DoD CAC. They're usually 10 digits long.
For instance the lowest EDIPI based UID we have currently is something like 1004201873 and the largest is 1658224121. (I made those but they're close to the actual UIDs.)
ipa idrange-find show me this, (did some masking of the info):
Range name: domain_id_range First Posix ID of the range: 824xxx000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000
Range name: domain_subid_range First Posix ID of the range: 214xxx3648 Number of IDs in the range: 214xxx2576 First RID of the corresponding RID range: 214xxx3648 Domain SID of the trusted domain: S-1-5-21-xxxxxx-83xx66-82xxx729 Range type: Active Directory domain range
Should I adjust the range that's already there or add a third that encompasses the likely range of numbers I'm gonna see in the future? I started to add a range with appropriate values but when it wanted the primary and secondary RID base values I was not sure how to figure that out or estimate.
Uhm.. I had a similar problem recently (but not identical), and it smells as a missing SID problem.
You can try:
ipa user-show admin --all | grep -i ipantsecurityidentifier
You should see the SID for user admin. Now try the same with your account:
ipa user-show <yourusername> --all | grep -i ipantsecurityidentifier
If nothing appears your user (and probably many other) is missing SID. If this is the case you can try:
ipa config-mod --enable-sid --add-sids
HTH
Ciao, gc
On 31/01/2024 16:18, Steve Berg via FreeIPA-users wrote:
For a few weeks now I've been seeing a problem getting authenticated to my ipa domain. I can get command line and web UI stuff done by using the admin user but if I get a ticket using my account which is in the admins group I get the following on the web UI:
Your session has expired. Please log in again.
On the command line any ipa commands I've tried so far give me:
ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)
Getting a ticket as admin on command line lets me run ipa commands with no problem. I think I've got all pertinent certificates loaded up properly. Gonna try a reboot on one of the servers shortly. I have 4 servers on r different vlans, replication between seems to be working properly.
I think the problem is most of the user ID's we use on this domain are not in the ID range configured. We let the install choose a default range when we first set this up. Most of our users have a UID based on their EDIPI # which is a 32-bit ID assigned when a user first gets a DoD CAC. They're usually 10 digits long.
For instance the lowest EDIPI based UID we have currently is something like 1004201873 and the largest is 1658224121. (I made those but they're close to the actual UIDs.)
ipa idrange-find show me this, (did some masking of the info):
Range name: domain_id_range First Posix ID of the range: 824xxx000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000
Range name: domain_subid_range First Posix ID of the range: 214xxx3648 Number of IDs in the range: 214xxx2576 First RID of the corresponding RID range: 214xxx3648 Domain SID of the trusted domain: S-1-5-21-xxxxxx-83xx66-82xxx729 Range type: Active Directory domain range
Should I adjust the range that's already there or add a third that encompasses the likely range of numbers I'm gonna see in the future? I started to add a range with appropriate values but when it wanted the primary and secondary RID base values I was not sure how to figure that out or estimate.
-- //- Fixer of that which is broke -// //- Home =sberg@mississippi.com -// //- Sinners can repent, but stupid is forever. -//
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Yep, most of the users do not have that SID. Looks like just users that are in the ID range because they don't have an EDIPI or users that were created recently.
Ran the --enable-sid and --add-sids but nothing changed. All the users that were missing the SID before still are.
On 1/31/24 10:06, Giulio Casella via FreeIPA-users wrote:
Uhm.. I had a similar problem recently (but not identical), and it smells as a missing SID problem.
You can try:
ipa user-show admin --all | grep -i ipantsecurityidentifier
You should see the SID for user admin. Now try the same with your account:
ipa user-show <yourusername> --all | grep -i ipantsecurityidentifier
If nothing appears your user (and probably many other) is missing SID. If this is the case you can try:
ipa config-mod --enable-sid --add-sids
HTH
Ciao, gc
On 31/01/2024 16:18, Steve Berg via FreeIPA-users wrote:
For a few weeks now I've been seeing a problem getting authenticated to my ipa domain. I can get command line and web UI stuff done by using the admin user but if I get a ticket using my account which is in the admins group I get the following on the web UI:
Your session has expired. Please log in again.
On the command line any ipa commands I've tried so far give me:
ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)
Getting a ticket as admin on command line lets me run ipa commands with no problem. I think I've got all pertinent certificates loaded up properly. Gonna try a reboot on one of the servers shortly. I have 4 servers on r different vlans, replication between seems to be working properly.
I think the problem is most of the user ID's we use on this domain are not in the ID range configured. We let the install choose a default range when we first set this up. Most of our users have a UID based on their EDIPI # which is a 32-bit ID assigned when a user first gets a DoD CAC. They're usually 10 digits long.
For instance the lowest EDIPI based UID we have currently is something like 1004201873 and the largest is 1658224121. (I made those but they're close to the actual UIDs.)
ipa idrange-find show me this, (did some masking of the info):
Range name: domain_id_range First Posix ID of the range: 824xxx000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000
Range name: domain_subid_range First Posix ID of the range: 214xxx3648 Number of IDs in the range: 214xxx2576 First RID of the corresponding RID range: 214xxx3648 Domain SID of the trusted domain: S-1-5-21-xxxxxx-83xx66-82xxx729 Range type: Active Directory domain range
Should I adjust the range that's already there or add a third that encompasses the likely range of numbers I'm gonna see in the future? I started to add a range with appropriate values but when it wanted the primary and secondary RID base values I was not sure how to figure that out or estimate.
-- //- Fixer of that which is broke -// //- Home =sberg@mississippi.com -// //- Sinners can repent, but stupid is forever. -//
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Ok, maybe you are missing some id range... Let's check this page, just to point in the right direction:
https://www.linuxsysadmins.com/ipa-error-4203-databaseerror/
(I had that error, after a couple of migration: CentOS 7 -> CentOS 8 stream -> RHEL 9).
Briefly: - "ipa idrange-find" should give id range (and subid range, but ignore it for now): write down "First Posix ID..." and "Number of IDs..." - "ipa-replica-manage dnarange-show" should give current dna ranges (maybe you have no dna range right now) - create dna ranges with "ipa-replica-manage dnarange-set server1.ipa.example.com 10000-20000" for every domain controller (range should be different for every server and included in range got from idrange-find)
If you manage to have correct ID ranges (and DNA ranges), don't forget to fire the sids creation command at end.
This procedure helped me to solve, I don't know if this is the correct way to go. Maybe some list guru out there can correct me.
Good luck.
On 31/01/2024 18:17, Steve Berg via FreeIPA-users wrote:
Yep, most of the users do not have that SID. Looks like just users that are in the ID range because they don't have an EDIPI or users that were created recently.
Ran the --enable-sid and --add-sids but nothing changed. All the users that were missing the SID before still are.
On 1/31/24 10:06, Giulio Casella via FreeIPA-users wrote:
Uhm.. I had a similar problem recently (but not identical), and it smells as a missing SID problem.
You can try:
ipa user-show admin --all | grep -i ipantsecurityidentifier
You should see the SID for user admin. Now try the same with your account:
ipa user-show <yourusername> --all | grep -i ipantsecurityidentifier
If nothing appears your user (and probably many other) is missing SID. If this is the case you can try:
ipa config-mod --enable-sid --add-sids
HTH
Ciao, gc
On 31/01/2024 16:18, Steve Berg via FreeIPA-users wrote:
For a few weeks now I've been seeing a problem getting authenticated to my ipa domain. I can get command line and web UI stuff done by using the admin user but if I get a ticket using my account which is in the admins group I get the following on the web UI:
Your session has expired. Please log in again.
On the command line any ipa commands I've tried so far give me:
ipa: ERROR: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty)
Getting a ticket as admin on command line lets me run ipa commands with no problem. I think I've got all pertinent certificates loaded up properly. Gonna try a reboot on one of the servers shortly. I have 4 servers on r different vlans, replication between seems to be working properly.
I think the problem is most of the user ID's we use on this domain are not in the ID range configured. We let the install choose a default range when we first set this up. Most of our users have a UID based on their EDIPI # which is a 32-bit ID assigned when a user first gets a DoD CAC. They're usually 10 digits long.
For instance the lowest EDIPI based UID we have currently is something like 1004201873 and the largest is 1658224121. (I made those but they're close to the actual UIDs.)
ipa idrange-find show me this, (did some masking of the info):
Range name: domain_id_range First Posix ID of the range: 824xxx000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000
Range name: domain_subid_range First Posix ID of the range: 214xxx3648 Number of IDs in the range: 214xxx2576 First RID of the corresponding RID range: 214xxx3648 Domain SID of the trusted domain: S-1-5-21-xxxxxx-83xx66-82xxx729 Range type: Active Directory domain range
Should I adjust the range that's already there or add a third that encompasses the likely range of numbers I'm gonna see in the future? I started to add a range with appropriate values but when it wanted the primary and secondary RID base values I was not sure how to figure that out or estimate.
-- //- Fixer of that which is broke -// //- Home =sberg@mississippi.com -// //- Sinners can repent, but stupid is forever. -//
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Still not working. I do not have any trust set up with any active directory currently, we have a AD running on the network but that and my ipa domain don't trust each other in any way.
Got two idranges setup: ----------- Range name: domain_id_range First Posix ID of the range: 824400000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range
Range name: EDIPIs_id_range First Posix ID of the range: 1009210100 Number of IDs in the range: 619332697 Range type: local domain range -----------
And dnarange/dnanextrange is setup also. The dnanext ranges match up to the EDIPIs range. ----------- [root@ipa02 ~]# ipa-replica-manage dnarange-show ipa25.domain: 824400015-824425499 ipa08.domain: 824550503-824599999 ipa22.domain: 824450504-824500499 ipa02.domain: 824425523-824450499 [root@ipa02 ~]# ipa-replica-manage dnanextrange-show ipa25.domain: 1464499522-1619332666 ipa08.domain: 1154833194-1309666338 ipa22.domain: 1309666348-1464499502 ipa02.domain: 1009210100-1154833174
-----------
Tried running the add-sids process and it errors out. There's nothing in the error log ----------- [root@ipa02 ~]# ipa -vv config-mod --enable-sid --add-sids ipa: INFO: Request: { "id": 0, "method": "config_mod/1", "params": [ [], { "add_sids": true, "enable_sid": true, "version": "2.251" } ] } ipa: INFO: Response: { "error": { "code": 4000, "data": {}, "message": "Configuration of SID failed. See details in the error log", "name": "ExecutionError" }, "id": 0, "principal": "admin@domain", "result": null, "version": "4.9.12" } ipa: ERROR: Configuration of SID failed. See details in the error log -----------
There's nothing in /var/log/dirsrv/slapd-DOMAIN/errors about the failure. So I'm at a roadblock right now. Can't do what I need to do and can't figure out why.
On 2/1/24 02:13, Giulio Casella via FreeIPA-users wrote:
Ok, maybe you are missing some id range... Let's check this page, just to point in the right direction:
https://www.linuxsysadmins.com/ipa-error-4203-databaseerror/
(I had that error, after a couple of migration: CentOS 7 -> CentOS 8 stream -> RHEL 9).
Briefly:
- "ipa idrange-find" should give id range (and subid range, but ignore
it for now): write down "First Posix ID..." and "Number of IDs..."
- "ipa-replica-manage dnarange-show" should give current dna ranges
(maybe you have no dna range right now)
- create dna ranges with "ipa-replica-manage dnarange-set
server1.ipa.example.com 10000-20000" for every domain controller (range should be different for every server and included in range got from idrange-find)
If you manage to have correct ID ranges (and DNA ranges), don't forget to fire the sids creation command at end.
This procedure helped me to solve, I don't know if this is the correct way to go. Maybe some list guru out there can correct me.
Good luck.
Hi,
On Thu, Feb 1, 2024 at 12:51 PM Steve Berg via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote:
Still not working. I do not have any trust set up with any active directory currently, we have a AD running on the network but that and my ipa domain don't trust each other in any way.
Got two idranges setup:
Range name: domain_id_range First Posix ID of the range: 824400000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range
Range name: EDIPIs_id_range First Posix ID of the range: 1009210100 Number of IDs in the range: 619332697 Range type: local domain range
The above range is missing RID base and secondary rid base. You can refer to this KCS: https://access.redhat.com/solutions/7052703 especially section *3. **Fixing ID range issues*. You will have to add ipabaserid and ipasecondarybaserid to the range. RID Values from 1,000-200,999 and 100,000,000-100,199,999 are already taken by the id range domain_id_range, you can pick any values not overlapping. flo
And dnarange/dnanextrange is setup also. The dnanext ranges match up to the EDIPIs range.
[root@ipa02 ~]# ipa-replica-manage dnarange-show ipa25.domain: 824400015-824425499 ipa08.domain: 824550503-824599999 ipa22.domain: 824450504-824500499 ipa02.domain: 824425523-824450499 [root@ipa02 ~]# ipa-replica-manage dnanextrange-show ipa25.domain: 1464499522-1619332666 ipa08.domain: 1154833194-1309666338 ipa22.domain: 1309666348-1464499502 ipa02.domain: 1009210100-1154833174
Tried running the add-sids process and it errors out. There's nothing in the error log
[root@ipa02 ~]# ipa -vv config-mod --enable-sid --add-sids ipa: INFO: Request: { "id": 0, "method": "config_mod/1", "params": [ [], { "add_sids": true, "enable_sid": true, "version": "2.251" } ] } ipa: INFO: Response: { "error": { "code": 4000, "data": {}, "message": "Configuration of SID failed. See details in the error log", "name": "ExecutionError" }, "id": 0, "principal": "admin@domain", "result": null, "version": "4.9.12" } ipa: ERROR: Configuration of SID failed. See details in the error log
There's nothing in /var/log/dirsrv/slapd-DOMAIN/errors about the failure. So I'm at a roadblock right now. Can't do what I need to do and can't figure out why.
On 2/1/24 02:13, Giulio Casella via FreeIPA-users wrote:
Ok, maybe you are missing some id range... Let's check this page, just to point in the right direction:
https://www.linuxsysadmins.com/ipa-error-4203-databaseerror/
(I had that error, after a couple of migration: CentOS 7 -> CentOS 8 stream -> RHEL 9).
Briefly:
- "ipa idrange-find" should give id range (and subid range, but ignore
it for now): write down "First Posix ID..." and "Number of IDs..."
- "ipa-replica-manage dnarange-show" should give current dna ranges
(maybe you have no dna range right now)
- create dna ranges with "ipa-replica-manage dnarange-set
server1.ipa.example.com 10000-20000" for every domain controller (range should be different for every server and included in range got from idrange-find)
If you manage to have correct ID ranges (and DNA ranges), don't forget to fire the sids creation command at end.
This procedure helped me to solve, I don't know if this is the correct way to go. Maybe some list guru out there can correct me.
Good luck.
-- //- Fixer of that which is broke -// //- Home = sberg@mississippi.com -// //- Sinners can repent, but stupid is forever. -//
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Is there anyway to just delete all these SID requirements? My ipa domain doesn't have a trust to anything windows and there's no plan to ever set that up.
Been trying to add the RID and it fails but doesn't tell me why it failed.
On 2/1/24 11:43, Florence Blanc-Renaud via FreeIPA-users wrote:
Hi,
On Thu, Feb 1, 2024 at 12:51 PM Steve Berg via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Still not working. I do not have any trust set up with any active directory currently, we have a AD running on the network but that and my ipa domain don't trust each other in any way. Got two idranges setup: ----------- Range name: domain_id_range First Posix ID of the range: 824400000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range Range name: EDIPIs_id_range First Posix ID of the range: 1009210100 Number of IDs in the range: 619332697 Range type: local domain range -----------The above range is missing RID base and secondary rid base. You can refer to this KCS: https://access.redhat.com/solutions/7052703especially section *3. **Fixing ID range issues*. You will have to add ipabaseridand ipasecondarybaseridto the range. RID Values from 1,000-200,999and 100,000,000-100,199,999are already taken by the id range domain_id_range, you can pick any values not overlapping. flo
On Чцв, 01 лют 2024, Steve Berg via FreeIPA-users wrote:
Is there anyway to just delete all these SID requirements? My ipa domain doesn't have a trust to anything windows and there's no plan to ever set that up.
No.
S4U protocol extensions for Kerberos are requiring PAC buffers presence as per the MS-SFU spec. The changes came in in 2021 as a part of the fixes to 'dollar sign attack'. You can get a partial view of that with https://wiki.samba.org/index.php/Security/Dollar_Ticket_Attack or several talks we gave over past few years at various conferences. Most notable: - Andrew Bartlett, "sambaXP 2022: The Inside Story on the Dollar Ticket Attack" https://www.youtube.com/watch?v=1BnraIAcybg
- Andreas Schneider, Alexander Bokovoy, "sambaXP 2023: Samba AD / MIT Kerberos: path out of experimental" https://www.youtube.com/watch?v=0_cdYuIYw0o
As such, you may be able to disable PAC generation to individual service principals with 'ipa service-mod --pac-type NONE service_principal' but if these principals would be using S4U protocol extensions (S4U2Self or S4U2Proxy), this cannot be done because these extensions require use of PAC structure and PAC structure requires SIDs. Specifically, FreeIPA API and Web UI rely on S4U extensions internally.
This is not a theoretical issue in IPA environment. There is working exploit that can be used to break through when SIDs aren't enforced in pure Kerberos environment. We fixed it in upstream MIT Kerberos and FreeIPA some time ago but the change required ABI break which we cannot allow in RHEL 8 due to details of Kerberos libraries support level. We had to find a different way.
For deployments using RHEL 8 since RHEL 8.5 SIDs generated by default. For deployments upgraded to new version, an update needs to be done by administrators but that requires changes specific to each deployment. Red Hat support folks wrote two articles which help with the upgrade process.
https://access.redhat.com/articles/7027037 explains how POSIX ID ranges and SID information is connected together.
https://access.redhat.com/solutions/7052703 explains how to adjust IPA deployment to upgrade to enable SIDs.
Both articles available to RHEL subscribers, including users of the free developer subscription, https://developers.redhat.com/
Been trying to add the RID and it fails but doesn't tell me why it failed.
Can you share what you have tried?
On 2/1/24 11:43, Florence Blanc-Renaud via FreeIPA-users wrote:
Hi,
On Thu, Feb 1, 2024 at 12:51 PM Steve Berg via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Still not working. I do not have any trust set up with any active directory currently, we have a AD running on the network but that and my ipa domain don't trust each other in any way.
Got two idranges setup:
Range name: domain_id_range First Posix ID of the range: 824400000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range
Range name: EDIPIs_id_range First Posix ID of the range: 1009210100 Number of IDs in the range: 619332697 Range type: local domain range
The above range is missing RID base and secondary rid base. You can refer to this KCS: https://access.redhat.com/solutions/7052703especially section *3. **Fixing ID range issues*. You will have to add ipabaseridand ipasecondarybaseridto the range. RID Values from 1,000-200,999and 100,000,000-100,199,999are already taken by the id range domain_id_range, you can pick any values not overlapping. flo
-- //- Fixer of that which is broke -// //- Home =sberg@mississippi.com -// //- Sinners can repent, but stupid is forever. -//
On Fri, Feb 02, 2024 at 12:11:58AM +0200, Alexander Bokovoy via FreeIPA-users wrote:
On Чцв, 01 лют 2024, Steve Berg via FreeIPA-users wrote:
Is there anyway to just delete all these SID requirements? My ipa domain doesn't have a trust to anything windows and there's no plan to ever set that up.
No.
S4U protocol extensions for Kerberos are requiring PAC buffers presence as per the MS-SFU spec. The changes came in in 2021 as a part of the fixes to 'dollar sign attack'. You can get a partial view of that with https://wiki.samba.org/index.php/Security/Dollar_Ticket_Attack or several talks we gave over past few years at various conferences. Most notable:
Andrew Bartlett, "sambaXP 2022: The Inside Story on the Dollar Ticket Attack" https://www.youtube.com/watch?v=1BnraIAcybg
Andreas Schneider, Alexander Bokovoy, "sambaXP 2023: Samba AD / MIT Kerberos: path out of experimental" https://www.youtube.com/watch?v=0_cdYuIYw0o
Those attacks are against MS Windows (and Samba?) I would say they're not relevant to majority of FreeIPA deployments, which have nothing to do with Windows.
On Пят, 02 лют 2024, Tomasz Torcz via FreeIPA-users wrote:
On Fri, Feb 02, 2024 at 12:11:58AM +0200, Alexander Bokovoy via FreeIPA-users wrote:
On Чцв, 01 лют 2024, Steve Berg via FreeIPA-users wrote:
Is there anyway to just delete all these SID requirements? My ipa domain doesn't have a trust to anything windows and there's no plan to ever set that up.
No.
S4U protocol extensions for Kerberos are requiring PAC buffers presence as per the MS-SFU spec. The changes came in in 2021 as a part of the fixes to 'dollar sign attack'. You can get a partial view of that with https://wiki.samba.org/index.php/Security/Dollar_Ticket_Attack or several talks we gave over past few years at various conferences. Most notable:
Andrew Bartlett, "sambaXP 2022: The Inside Story on the Dollar Ticket Attack" https://www.youtube.com/watch?v=1BnraIAcybg
Andreas Schneider, Alexander Bokovoy, "sambaXP 2023: Samba AD / MIT Kerberos: path out of experimental" https://www.youtube.com/watch?v=0_cdYuIYw0o
Those attacks are against MS Windows (and Samba?) I would say they're not relevant to majority of FreeIPA deployments, which have nothing to do with Windows.
You are wrong here. It is a common problem since majority of users do not understand Kerberos protocol extensions and their use by FreeIPA or other domain services like Samba AD or Active Directory.
Since its inception, FreeIPA has depended on S4U extensions to Kerberos to allow IPA services operate on behalf of users. This is used by IPA API, for example, to allow IPA management framework to talk to LDAP on behalf of the user and LDAP server to recognize that this connection is authenticated as the user, not IPA management framework account.
This extension was developed by Microsoft for Active Directory to allow domain member machines to operate on behalf of the user when mounting home directories (shares) or allowing web servers to ask for other resources (file shares or SQL server connections) on behalf of the user.
All these technical elements are part of a constrained delegation feature that both Active Directory implementations and FreeIPA are using internally. You can read about constrained delegation forms in more details in [1].
There are several different attacks that were developed against S4U extensions and they are protocol level attacks.
A Kerberos ticket received by the service through S4U2Self extension is supposed to be non-forwardable but 'forwardable' bit is placed in the area which is under control of the service asking for the ticket. Hence, a rogue service can flip the 'forwardable' bit and KDC will not be able to tell the difference: the area is checksummed with a key based on the service's key. It was supposed to be a protocol extension that only allowed issuing tickets to itself and not allowing to use it elsewhere. It is not anymore: this bit flip allows to use a ticket printed by the rogue service against any other allowed service in the environment using the second part of S4U extensions, S4U2Proxy. The latter is the extension used by IPA as the core one for IPA API operations.
To prevent this attack, a protocol change was added to introduce additional checksums which aren't under control of the rogue service. There are actually two separate checksums: one them was found to be possible to attack via pre-imaging operation against the hash algorithm, so another one was added to close the problem down.
The only way to prevent these attacks on the checksums and Kerberos ticket properties was by introducing additional details in the tickets that cannot be controlled by the attackers. This is done via a set of extensions that handle authorization data (AD) information in the Kerberos tickets. MS-PAC describes one of AD buffer types and PAC records are required for S4U operations. Use of S4U operations since 2020 requires several types of PAC records, all protected from modifications.
On top of that, use of Kerberos tickets without PAC information opens an easy attack vector to POSIX environments. PAC allows KDC to place identity details into Kerberos tickets so that Kerberos services can corelate Kerberos principal with the information they know about identity of this principal in their environment. Since SSSD and Samba (winbindd) do explicit SID to POSIX user/group name translation, information from PAC records can be used to identify not just the Kerberos principal to POSIX account/group mapping but also to figure out whether this principal is of right shape (e.g. it is a valid user rather than a service or a machine account). This prevents mistyping attacks like mapping a machine account 'root$' to 'root' POSIX user.
People in both white hat and black hat communities weren't really attacking FreeIPA through these issues because most of the tools they use lack features required by the Kerberos implementation in FreeIPA. For example, FreeIPA defaults to newer Kerberos encryption types defined in RFC 8009 which Windows still do not support. Neither those common tools (e.g. Rubeus, Impacket, etc.) have support for newer checksums.
Over past three years some of those tools were fixed so what required using C code and MIT or Heimdal Kerberos directly is more accessible to wider public now. In addition to that, Samba AD fixes to the same issues led to creation of extensive Kerberos test suite that all of us are using for conformance. Obviously, it is a double-edged sword in the IT warfare.
Julien Rische did a talk[2] at FOSDEM 2024 to explain how these attacks work in detail. This is result of a work we did to backport some of the protection work to RHEL 8 releases. RHEL 8 uses older MIT Kerberos version which cannot be fixed the same way as RHEL 9 due to ABI incompatibilities and ACG guaranties RHEL 8 gives. We relied on the presence of PAC and certain information that FreeIPA KDB driver posseses about the Kerberos principals to prevent those attacks.
[1] https://freeipa.readthedocs.io/en/latest/designs/rbcd.html [2] https://fosdem.org/2024/schedule/event/fosdem-2024-2681-fixing-a-kerberos-vu...
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Florence Blanc-Renaud -
Giulio Casella -
Steve Berg -
Tomasz Torcz