control PKI (& other relevant listened-on address/interface - ?
by lejeczek
Hi.
Having more ifaces added to the system I have had http/www
portion of IPA run on specific - as opposed to all/any - ip
addresses and perfectly, problem-free.
I need to do the same with remaining bits but have to start
with :8443 which I believed was Tomcat, so did add 'address'
into 'server.xml' in /usr/share/tomcat/conf/ but that is not
doing it?
Where, which bits have to change - even if against best
practice & IPA recommendation - to make those IPA components
bind to specific ifaces/ip address?
many thanks, L.
11 months, 1 week
sftp HBAC
by Kevin Vasko
Try to make this simple.
Have a HBAC, have the "Who" set to a user, have the "Accessing" set to a
server.
Have the "Via Service" set to "sshd". The user can ssh into the server no
issue.
I want to limit this user to only being able to sftp into this server (no
direct ssh).
If I swap the "Via Service" from the sshd service to sftp that user is now
denied. They cannot access the server via sftp or ssh. I would expect it to
deny ssh access but allow sftp.
I did copy "cp /etc/pam.d/sshd /etc/pam.d/sftp" as I saw it mentioned here
https://freeipa-users.redhat.narkive.com/tFQFZmNu/hbac-service-allowed-de...
but that didn't seem to work.
Can you point me to the instructions on how to make the HBAC work with a
particular service (e.g. sftp)?
11 months, 1 week
IDView problem
by Ronald Wimmer
I tried to apply an ID-View to a single AD-User. The first thing I
noticed that the short user name did not work anymore upon SSH login. I
had to specifiy the user name with its FQDN.
The second problem I noticed is that under RHEL 9 that particular user
somehow "lost" all its groups. The only group the id command revealed
was the one with the user's UID. So group-based sudo permissions stopped
working...
Cheers,
Ronald
11 months, 2 weeks
IPA filters not working
by Omar Pagan
Hello,
I have setup a bastion host with an IPA client in order to control access to the bastion host by groups. I have users in different groups, but I just got word that people outside the group / HBAC rule can access and login with their IPA credentials. Everything seems okay with the configuration.
I have uninstalled and re-installed the client, generating a new SSSD config file, yet the user still accessing the bastion host. Thoughts?
11 months, 2 weeks
Re: Authentication failures on a RHEL 9.2 IPA server
by Rob Crittenden
Charles Hedrick via FreeIPA-users wrote:
> OK, so I see the answer to my problem is to run
>
> ipa config-mod --add-sids --enable-sid
>
> But we have old UIDs that with low numbers. It looks like I need to do
>
> ipa idrange-add CS.RUTGERS.EDU_low_id_range --base-id=1
> --range-size=200000 --rid-base=200000000 --secondary-rid-base=300000000
> ipa idrange-add CS.RUTGERS.EDU_mid_id_range --base-id=600000
> --range-size=200000 --rid-base=400000000 --secondary-rid-base=500000000
>
> In order for ipa user-add for those UIDs to work on any system,
> presumably I have to do that on all IPA servers. Is that OK? I'm
> assuming new id's where we don't specify a UID will be put in the same
> range before, which is different on each server.
Ranges are global, not per-server. So assuming your ranges are ok and
there are no overlaps for the IDs or RID ranges this is probably ok, but
I'm not a PAC expert.
I think what you're seeing is the DNA (Distributed Numeric Assignment)
plugin at work.
On the first installed server, DNA has the full range of id_range values
to generate UIDs and GIDs. The first time a replica needs to generate a
UID/GID it requests a range and gets half of the allocation. A replica
does not automatically get a range on install. The more servers you have
AND the more replicas you've added entries on, the smaller the available
ranges may be. You can use ipa-replica-manage to display and manipulate
the ranges.
rob
>
>
>
>
>
> ------------------------------------------------------------------------
> *From:* Sam Morris via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
> *Sent:* Monday, May 15, 2023 8:08 AM
> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> *Cc:* Alexander Bokovoy <abokovoy(a)redhat.com>; Sam Morris
> <sam(a)robots.org.uk>
> *Subject:* [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA
> server
>
> On Mon, May 15, 2023 at 09:28:22AM +0300, Alexander Bokovoy via
> FreeIPA-users wrote:
>> On su, 14 touko 2023, Sam Morris wrote:
>> > On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users wrote:
>> > > I wonder about the root cause; is this because MIT Kerberos 1.20 always
>> > > wants to include a PAC in its issued TGTs, and it gives up if it can't
>> > > retrieve a user's SID from the directory? (If so I wonder if setting
>> > > disable_pac = true in the realm section of krb5.conf would have worked
>> > > around the problem?)
>> >
>> > This seems to be the case. Specifically I:
>> >
>> > 1. Removed the ipantsecurityidentifier attribute from a user, and
>> > removed ipantuserattrs from the user's objectclass
>> > 2. Tried to log in as the user & got the same failures + 'No such file
>> > or directory' message in /var/log/krb5kdc.log
>> > 3. Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true'
>> > within the realm-specific configuration in the realms section
>> > 4. Restarted krb5kdc
>> > 5. Tried to log in as the user and it worked!
>> >
>> > The docs for disable_pac say:
>> >
>> > If true, the KDC will not issue PACs for this realm, and S4U2Self
>> > and S4U2Proxy operations will be disabled. The default is false,
>> > which will permit the KDC to issue PACs. New in release 1.20.
>> >
>> > ... which doesn't explain that if the KDC can't issue a PAC for some
>> > reason then the KDC will fail to issue the TGT. But at least I've gotten
>> > to the bottom of things now. :)
>>
>> RHEL IdM documentation has a separate chapter related to it.
>>
>> RHEL 9:
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/...
>>
>> RHEL 8:
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
>>
>> This documentation is in place since summer 2022.
>
> Brilliant. It's interesting that the docs say "As of RHEL 8.6, Kerberos
> in IdM requires that your IdM objects have SIDs, which are necessary for
> security based on Privilege Access Certificate (PAC) information.", but
> I had no problems with authentication on my RHEL 8.6/8.7 servers...
>
>> > > "After upgrading, krb5kdc may fail to issue TGTs to users who have not
>> > > had a SID assigned to their accounts ('ipa user-show user --all' will
>> > > not include an ipantsecurityidentifier attribute). In this case
>> > > krb5kdc.log will log a message "HANDLE_AUTHDATA: user(a)EXAMPLE.COM for
>> > > krbtgt/EXAMPLE.COM(a)EXAMPLE.COM, No such file or directory". This can be
>> > > fixed by running 'ipa config-mod --enable-sid --add-sids' as an IPA
>> > > admin on another IPA server."
>> >
>> > ... "or on the same server after temporarily setting "disable_pac =
>> > true" in kdc.conf, and restarting krb5kdc."
>>
>> You should not be disabling PAC because you are really setting yourself
>> up to an attack with a known exploit out in a wild.
>
> Absolutely--I just wanted to document what I'd found out, because there
> isn't a clear connection documented between the behaviour in RHEL 9.2
> with MIT Kerberos 1.20 and the behaviour seen when your IPA users don't
> have SIDs assigned.
>
> --
> Sam Morris <https://robots.org.uk/>
> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
11 months, 2 weeks
Re: can't kinit after upgrade to redhat 9.2
by Sam Morris
On 15/05/2023 19:00, Charles Hedrick via FreeIPA-users wrote:
> I just upgraded from redhat 9.0 to 9.2 on a set of kerberos servers,
> fortunately a test system. I can't kinit as existing users. If I add a
> user I can kinit as them. Changing the password doesn't help. krb5kdc says
>
>
> May 15 13:58:30 krb1.cs.rutgers.edu krb5kdc[652884](info): AS_REQ (4
> etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20),
> aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)})
> 128.6.157.187: HANDLE_AUTHDATA: clh(a)CS.RUTGERS.EDU for
> kadmin/changepw(a)CS.RUTGERS.EDU, No such file or directory
>
> The only difference I see in ldap attributes between the existing and
> new user is that the new user has
> ipaNTSecurityIdentifier: S-1-5-21-3719230765-1403434741-3275474567-88461
> and
> objectClass: ipantuserattrs
>
> We are not using anything Windows-related
You need to run 'ipa config-mod --enable-sid --add-sids' on one of your
servers. See
<https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/...>.
--
Sam Morris <https://robots.org.uk/>
PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
11 months, 2 weeks
Re: Authentication failures on a RHEL 9.2 IPA server
by Rob Crittenden
Charles Hedrick via FreeIPA-users wrote:
> is there a way to do a bulk update of existing users? We have this
> issue. I can disable the pac, but that might not be a good long term
> solution
It's in section 12.2 of the linked RHEL 9 documentation.
rob
> ------------------------------------------------------------------------
> *From:* Sam Morris via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
> *Sent:* Monday, May 15, 2023 8:08 AM
> *To:* FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
> *Cc:* Alexander Bokovoy <abokovoy(a)redhat.com>; Sam Morris
> <sam(a)robots.org.uk>
> *Subject:* [Freeipa-users] Re: Authentication failures on a RHEL 9.2 IPA
> server
>
> On Mon, May 15, 2023 at 09:28:22AM +0300, Alexander Bokovoy via
> FreeIPA-users wrote:
>> On su, 14 touko 2023, Sam Morris wrote:
>> > On Fri, May 12, 2023 at 06:19:44PM +0100, Sam Morris via FreeIPA-users wrote:
>> > > I wonder about the root cause; is this because MIT Kerberos 1.20 always
>> > > wants to include a PAC in its issued TGTs, and it gives up if it can't
>> > > retrieve a user's SID from the directory? (If so I wonder if setting
>> > > disable_pac = true in the realm section of krb5.conf would have worked
>> > > around the problem?)
>> >
>> > This seems to be the case. Specifically I:
>> >
>> > 1. Removed the ipantsecurityidentifier attribute from a user, and
>> > removed ipantuserattrs from the user's objectclass
>> > 2. Tried to log in as the user & got the same failures + 'No such file
>> > or directory' message in /var/log/krb5kdc.log
>> > 3. Edited /var/kerberos/krb5kdc/kdc.conf, adding 'disable_pac = true'
>> > within the realm-specific configuration in the realms section
>> > 4. Restarted krb5kdc
>> > 5. Tried to log in as the user and it worked!
>> >
>> > The docs for disable_pac say:
>> >
>> > If true, the KDC will not issue PACs for this realm, and S4U2Self
>> > and S4U2Proxy operations will be disabled. The default is false,
>> > which will permit the KDC to issue PACs. New in release 1.20.
>> >
>> > ... which doesn't explain that if the KDC can't issue a PAC for some
>> > reason then the KDC will fail to issue the TGT. But at least I've gotten
>> > to the bottom of things now. :)
>>
>> RHEL IdM documentation has a separate chapter related to it.
>>
>> RHEL 9:
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/...
>>
>> RHEL 8:
>> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
>>
>> This documentation is in place since summer 2022.
>
> Brilliant. It's interesting that the docs say "As of RHEL 8.6, Kerberos
> in IdM requires that your IdM objects have SIDs, which are necessary for
> security based on Privilege Access Certificate (PAC) information.", but
> I had no problems with authentication on my RHEL 8.6/8.7 servers...
>
>> > > "After upgrading, krb5kdc may fail to issue TGTs to users who have not
>> > > had a SID assigned to their accounts ('ipa user-show user --all' will
>> > > not include an ipantsecurityidentifier attribute). In this case
>> > > krb5kdc.log will log a message "HANDLE_AUTHDATA: user(a)EXAMPLE.COM for
>> > > krbtgt/EXAMPLE.COM(a)EXAMPLE.COM, No such file or directory". This can be
>> > > fixed by running 'ipa config-mod --enable-sid --add-sids' as an IPA
>> > > admin on another IPA server."
>> >
>> > ... "or on the same server after temporarily setting "disable_pac =
>> > true" in kdc.conf, and restarting krb5kdc."
>>
>> You should not be disabling PAC because you are really setting yourself
>> up to an attack with a known exploit out in a wild.
>
> Absolutely--I just wanted to document what I'd found out, because there
> isn't a clear connection documented between the behaviour in RHEL 9.2
> with MIT Kerberos 1.20 and the behaviour seen when your IPA users don't
> have SIDs assigned.
>
> --
> Sam Morris <https://robots.org.uk/>
> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
>
11 months, 2 weeks
can't kinit after upgrade to redhat 9.2
by Charles Hedrick
I just upgraded from redhat 9.0 to 9.2 on a set of kerberos servers, fortunately a test system. I can't kinit as existing users. If I add a user I can kinit as them. Changing the password doesn't help. krb5kdc says
May 15 13:58:30 krb1.cs.rutgers.edu krb5kdc[652884](info): AS_REQ (4 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17)}) 128.6.157.187: HANDLE_AUTHDATA: clh(a)CS.RUTGERS.EDU for kadmin/changepw(a)CS.RUTGERS.EDU, No such file or directory
The only difference I see in ldap attributes between the existing and new user is that the new user has
ipaNTSecurityIdentifier: S-1-5-21-3719230765-1403434741-3275474567-88461
and
objectClass: ipantuserattrs
We are not using anything Windows-related
11 months, 2 weeks
When a cert-profile doesn't exist and can't see it but IPA thinks it does - how to correct?
by Nicholas Cross
We found that we have a cert profile that was deleted in the ui and then we attempted to re-create it, but it will not.
ipa: ERROR: Request failed with status 409: Non-2xx response from CA REST API: 409. Unable to create profile: Profile already exists
The profile does not show in the UI or via the CLI
$ ipa certprofile-find controlServersKubeAPIClustertest1
<blank>
$ ipa certprofile-show controlServersKubeAPIClustertest1
<blank>
But when checking ldap itself we can see it.
$ ldapsearch -LLL -o ldif-wrap=no -w $pass -D 'cn=Directory Manager' -b 'o=ipaca' | grep controlServersKubeAPIClustertest1
dn: cn=controlServersKubeAPIClustertest1,ou=certificateProfiles,ou=ca,o=ipaca
cn: controlServersKubeAPIClustertest1
extdata-profileid: controlServersKubeAPIClustertest1
metaInfo: profileId:controlServersKubeAPIClustertest1
extdata-profileid: controlServersKubeAPIClustertest1
metaInfo: profileId:controlServersKubeAPIClustertest1
extdata-profileid: controlServersKubeAPIClustertest1
metaInfo: profileId:controlServersKubeAPIClustertest1
extdata-profileid: controlServersKubeAPIClustertest1
metaInfo: profileId:controlServersKubeAPIClustertest1
extdata-profileid: controlServersKubeAPIClustertest1
metaInfo: profileId:controlServersKubeAPIClustertest1
Apart from doing an ldapdelete on that dn: , is there a better way to clean up that "ghost" cert profile? (and the corresponding certs?)
thanks,
Nick
11 months, 2 weeks
