[Freeipa-users] Re: Force LDAPS and 636 port
On ke, 08 helmi 2023, Алексей Иванов wrote: Greetings, Thanks a lot for your explanation. Based on your message and my humble research would it be safe to say that to enforce TLS connections with a specific ciphers to the default FreeIPA deployment one can do these: 1. Require secure bind nsslapd-require-secure-binds=on (will reject all the connections without STARTTLS) 2. Disabling Anonymous Binds nsslapd-allow-anonymous-access=rootdse (to allow read dir info) 3. Set nsSSL3Ciphers to ones we approve 4. Set sslVersionMin to the lower one we support I spoke to my security team and explained to them the situation with 389 and 636 ports. They agreed to comply with your advice but strictly told that it is mandatory to maintain secure communication using TLS and a certain number of ciphers they see as strong. Since you haven't really specified what FreeIPA or RHEL IdM version you are talking about in the setup above, I'd like to point that in RHEL/CentOS 8+ and Fedora we have crypto policies which make setting up at least (3) and (4) easy at system-wide level. It definitely should not be done on per-application basis. 389-ds already follows the system crypto policy in defining how TLS versions and ciphers get applied. If you need to amend settings by introducing a crypto policies' subpolicy, I'd suggest to consult man pages for 'update-crypto-policies(8)' and 'crypto-policies(7)'. Regards, Alex Ivanov On Tue, Jan 31, 2023 at 6:18 PM Alexander Bokovoy wrote: On ti, 31 tammi 2023, Alex Ivanov via FreeIPA-users wrote: >Greetings, > >I'm struggling to find a comprehensive guide on how to block LDAP and >389 port on FreeIPA and force usage of LDAPS and 636 port for all >clients and connections. I would really appreciate a link or a hint. There is no such guide because FreeIPA requires use of LDAP/389, both TCP and UDP, same as with Active Directory. We enforce encrypted connections within SASL GSSAPI-authenticated sessions. If you have requirements to close done port 389, well, tell those people to go and learn how domain resolution protocols are done in Active Directory and similar systems. LDAP use of port 636 is not really standardized (it was an RFC proposal that expired and not made into RFC at all). All the manual work to make it supported is not going to play well with the fact that Windows systems still required to talk port 389 for general domain controller discovery questions: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/7fcdce70-5205-44d6-9c3a-260e616a2f04 and then https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/895a7744-aff3-4f64-bcfa-f8c05915d2e9 If you are using Kerberos and SASL GSSAPI or SASL GSS-SPNEGO (default configuration for SSSD and RHEL IdM), none of disabling for LDAP 389 port is needed. This is because RHEL version of CyrusSASL automatically enables encryption and signing when Kerberos is in use with AES encryption types. We use LDAP SASL GSSAPI/GSS-SPNEGO to actually authenticate to IPA and AD LDAP resources. Due to how this is implemented in RHEL, such connections are then encrypted. This works everywhere, for example, there is no need to switch to port 3269 for Global Catalog traffic. From my email roughly three years ago, the same applies to any LDAP traffic with SASL GSSAPI/GSS-SPNEGO authentication, not just port 389 but 3268 as well: --- We added two important fixes in RHEL 7.4-7.5 timeframe: - RHEL 7.4: support GSS-SPNEGO in CyrusSASL, with cyrus-sasl-2.1.26-21 or later installed (https://bugzilla.redhat.com/show_bug.cgi?id=1421663), - RHEL 7.5: support autodiscovery of minimal SSF with GSSAPI/GSS-SPNEGO, with cyrus-sasl-2.1.26-22 or later installed (https://bugzilla.redhat.com/show_bug.cgi?id=1431586) These should be enough because SSSD uses LDAP with SASL based on CyrusSASL library and negotiates GSSAPI/GSS-SPNEGO with sealing (encryption) by default in all new RHEL 7/RHEL 8 deployments. We keep getting these questions from the customers for SSSD accessing AD LDAP all the time. Well, that was the case couple years ago, not anymore, except your email today. If you want to see that the traffic is encrypted, try without GSSAPI_* options in ldap.conf and I can see following with tshark in LDAP communication after bind was successfully performed. This is running 'ldapsearch -Y GSSAPI -h AD-DC -b $basedn cn=Administrator' Lightweight Directory Access Protocol SASL Buffer Length: 127 SASL Buffer GSS-API Generic Security Service Application Program Interface krb5_blob: 050406ff0262b065c0d8351b29fd1943<80> krb5_tok_id: KRB_TOKEN_CFX_WRAP (0x0405) krb5_cfx_flags: 0x06, AcceptorSubkey, Sealed .1.. = AcceptorSubkey: Set ..1. = Sealed: Set ...0 = SendByAcceptor: Not set As you can see, we do send encrypted (Sealed bit) traffic. AD DCs respond with sealed
[Freeipa-users] Re: Upgrade outdated FreeIPA sanity check
Appreciate the response. Unfortunately, I’ve got the hand i’ve been deal with. Our machines normally have 1-2 but if someone hardcodes a single DNS it’s probably going to the main server. The systems using DHCP would be fine…but for the ones that aren’t it will just all break. No matter, to me this seems all very complicated. In my eyes it would be way more fragile than a single dot version upgrade. Is FreeIPA that sensitive going from 4.5 to 4.6? Is FreeIPA really this fragile? I’ve honestly been nervous with this mess because I feel if something fails, I’ll never get it back running properly as it’s less like a “ok let’s reset and start over”. Honestly what I feel like my quickest and best approach is to snapshot all of the IPA systems, pick one to run yum update on and see what happens. If it breaks, simply revert all of them back. Would this be a really bad idea? -Kevin > On Feb 8, 2023, at 8:59 PM, Jernej Jakob wrote: > > I forgot one more option. Since the first server is older than the > other 2, you could not upgrade it but just shut it down. Follow the > procedures: promote one of the two newer servers to CA renewal master, > follow steps to decomission/remove the server from the domain, remove > DNS SRV and A/ records. Remove RUVs pointing to it. Then change the > IP of that server's NIC to something else, and assign its IP(s) to one > of the other 2 servers (add alias/es). So requests for DNS will then > hit one of the remaining servers. Someone more knowledgeable can > confirm if this is a good option - I personally did this and it worked > (temporarily until I can change the DNS settings on all machines with > static config). > >> On Thu, 9 Feb 2023 03:44:35 +0100 >> Jernej Jakob via FreeIPA-users >> wrote: >> >> On Wed, 8 Feb 2023 09:53:35 -0600 >> Kevin Vasko via FreeIPA-users >> wrote: >> >>> Thanks Rafael. >>> >>> I was hoping to do it in place if at all possible because where things get >>> complicated is the 4.5.4 server is also the internal DNS server that >>> everyone utilizes (we have multiple but people just use the 1 mainly). It >>> really was their "main" server. I added the other two replicas a few years >>> ago to make sure we had something. They contacted me and wanted help to >>> upgrade everything so here I am. Making any modifications to it will >>> probably make everything go heywire (or at least break DNS for everyone). >>> That is unless I get it back immediately by >>> >>> 1. adding a 4th server >>> 2. promoting the 4th server to master >>> 3. decommission the 4.5.4 server >>> 4. reassign the 4th server the same IP as the old 4.5.4 server? >>> 5. upgrade rest of servers >>> >>> Any thoughts? recommendations? >>> >> >> IMO they really should be using at least 2, if not all 3, of those as >> DNS servers. Then even if the primary is down, they should fail over to >> the secondary or tertiary (with the only symptom being slow resolving, >> so users will notice it, but will still be able to work). >> I've only noticed one thing in my network not failing over to secondary >> as it should, docker. If primary from resolv.conf is down, it will fail >> over to Google's 8.8.8.8 instead of your secondary. >> The other possibility is that you configure your firewall to DNAT >> all requests on UDP/TCP port 53 to the other, working server. But this >> will only work for requests coming from other networks which pass >> through your router. It's why I use lots of VLANs, I have all the IPA >> servers in their own VLAN so I could do this. But if you have other >> machines in the same network they won't be passing through the router >> so that won't be possible. >> The third possibility is that you set up DNAT with masquerading on the >> IPA server you will be upgrading, to translate packets to the other >> server, masquerade to make the reply packets go back through the same >> path (otherwise they may be dropped due to source IP mismatch). This >> will work for all requests including those not passing the router, but >> will only work while the OS is booted. So you can shut down IPA and it >> will work but if you need to restart the OS it will also go down. >> >>> On Wed, Feb 8, 2023 at 5:43 AM Rafael Jeffman wrote: >>> On Tue, Feb 7, 2023 at 6:29 PM Kevin Vasko via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > > We have a set of 3x freeIPA servers that have outdated (everything) in a > development/test environment that need to be updated. > > It seems that 4.6.8-5.el7.centos.12 is the latest version available on CentOS 7? > > We are at on the 3 servers: > 4.5.4-10.el7.centos.4.4 > 4.6.4-10-el7.centos.6 > 4.6.4-10-el7.centos.6 > > For the two 4.6.4 installs, that seems relatively simple upgrade as we would only be going to a different dot release and a simple "yum update ipa-server" should handle this? Is there
[Freeipa-users] Re: Upgrade outdated FreeIPA sanity check
I forgot one more option. Since the first server is older than the other 2, you could not upgrade it but just shut it down. Follow the procedures: promote one of the two newer servers to CA renewal master, follow steps to decomission/remove the server from the domain, remove DNS SRV and A/ records. Remove RUVs pointing to it. Then change the IP of that server's NIC to something else, and assign its IP(s) to one of the other 2 servers (add alias/es). So requests for DNS will then hit one of the remaining servers. Someone more knowledgeable can confirm if this is a good option - I personally did this and it worked (temporarily until I can change the DNS settings on all machines with static config). On Thu, 9 Feb 2023 03:44:35 +0100 Jernej Jakob via FreeIPA-users wrote: > On Wed, 8 Feb 2023 09:53:35 -0600 > Kevin Vasko via FreeIPA-users > wrote: > > > Thanks Rafael. > > > > I was hoping to do it in place if at all possible because where things get > > complicated is the 4.5.4 server is also the internal DNS server that > > everyone utilizes (we have multiple but people just use the 1 mainly). It > > really was their "main" server. I added the other two replicas a few years > > ago to make sure we had something. They contacted me and wanted help to > > upgrade everything so here I am. Making any modifications to it will > > probably make everything go heywire (or at least break DNS for everyone). > > That is unless I get it back immediately by > > > > 1. adding a 4th server > > 2. promoting the 4th server to master > > 3. decommission the 4.5.4 server > > 4. reassign the 4th server the same IP as the old 4.5.4 server? > > 5. upgrade rest of servers > > > > Any thoughts? recommendations? > > > > IMO they really should be using at least 2, if not all 3, of those as > DNS servers. Then even if the primary is down, they should fail over to > the secondary or tertiary (with the only symptom being slow resolving, > so users will notice it, but will still be able to work). > I've only noticed one thing in my network not failing over to secondary > as it should, docker. If primary from resolv.conf is down, it will fail > over to Google's 8.8.8.8 instead of your secondary. > The other possibility is that you configure your firewall to DNAT > all requests on UDP/TCP port 53 to the other, working server. But this > will only work for requests coming from other networks which pass > through your router. It's why I use lots of VLANs, I have all the IPA > servers in their own VLAN so I could do this. But if you have other > machines in the same network they won't be passing through the router > so that won't be possible. > The third possibility is that you set up DNAT with masquerading on the > IPA server you will be upgrading, to translate packets to the other > server, masquerade to make the reply packets go back through the same > path (otherwise they may be dropped due to source IP mismatch). This > will work for all requests including those not passing the router, but > will only work while the OS is booted. So you can shut down IPA and it > will work but if you need to restart the OS it will also go down. > > > > > On Wed, Feb 8, 2023 at 5:43 AM Rafael Jeffman wrote: > > > > > > > > > > > On Tue, Feb 7, 2023 at 6:29 PM Kevin Vasko via FreeIPA-users < > > > freeipa-users@lists.fedorahosted.org> wrote: > > > > > > > > We have a set of 3x freeIPA servers that have outdated (everything) in > > > > a > > > development/test environment that need to be updated. > > > > > > > > It seems that 4.6.8-5.el7.centos.12 is the latest version available on > > > > > > > CentOS 7? > > > > > > > > We are at on the 3 servers: > > > > 4.5.4-10.el7.centos.4.4 > > > > 4.6.4-10-el7.centos.6 > > > > 4.6.4-10-el7.centos.6 > > > > > > > > For the two 4.6.4 installs, that seems relatively simple upgrade as we > > > > > > > would only be going to a different dot release and a simple "yum update > > > ipa-server" should handle this? Is there any advisement for/against doing > > > a > > > full "yum update" on the entire system to get everything updated? > > > > > > > > For the 4.5.4 system, is there much of a concern going straight from > > > 4.5.4 to 4.6.8 straight? I assume the concern would be jumping major > > > versions and going from say 4.5 to 4.9? > > > > > > > > My current plan is to stop at CentOS 7.9 and latest FreeIPA 4.6 release > > > > > > > on CentOS 7.9. But for my own knowledge if I was going to 4.10 wouldn't > > > the > > > recommendation path to upgrade to 4.10, to install CentOS Stream 9 on a > > > new > > > server, enroll it, make 4.10 the master and then remove the CentOS 7 > > > instances? > > > > > > > > > > Assuming you can't have a 4th server, Is it possible for you to have only > > > 2 replicas for some time? If so, you can remove the 4.5.4 server, fully > > > (cleanly?) upgrade it, add it back, set it as CA master, and repeat the > > >
[Freeipa-users] Re: Upgrade outdated FreeIPA sanity check
On Wed, 8 Feb 2023 09:53:35 -0600 Kevin Vasko via FreeIPA-users wrote: > Thanks Rafael. > > I was hoping to do it in place if at all possible because where things get > complicated is the 4.5.4 server is also the internal DNS server that > everyone utilizes (we have multiple but people just use the 1 mainly). It > really was their "main" server. I added the other two replicas a few years > ago to make sure we had something. They contacted me and wanted help to > upgrade everything so here I am. Making any modifications to it will > probably make everything go heywire (or at least break DNS for everyone). > That is unless I get it back immediately by > > 1. adding a 4th server > 2. promoting the 4th server to master > 3. decommission the 4.5.4 server > 4. reassign the 4th server the same IP as the old 4.5.4 server? > 5. upgrade rest of servers > > Any thoughts? recommendations? > IMO they really should be using at least 2, if not all 3, of those as DNS servers. Then even if the primary is down, they should fail over to the secondary or tertiary (with the only symptom being slow resolving, so users will notice it, but will still be able to work). I've only noticed one thing in my network not failing over to secondary as it should, docker. If primary from resolv.conf is down, it will fail over to Google's 8.8.8.8 instead of your secondary. The other possibility is that you configure your firewall to DNAT all requests on UDP/TCP port 53 to the other, working server. But this will only work for requests coming from other networks which pass through your router. It's why I use lots of VLANs, I have all the IPA servers in their own VLAN so I could do this. But if you have other machines in the same network they won't be passing through the router so that won't be possible. The third possibility is that you set up DNAT with masquerading on the IPA server you will be upgrading, to translate packets to the other server, masquerade to make the reply packets go back through the same path (otherwise they may be dropped due to source IP mismatch). This will work for all requests including those not passing the router, but will only work while the OS is booted. So you can shut down IPA and it will work but if you need to restart the OS it will also go down. > > On Wed, Feb 8, 2023 at 5:43 AM Rafael Jeffman wrote: > > > > > > > On Tue, Feb 7, 2023 at 6:29 PM Kevin Vasko via FreeIPA-users < > > freeipa-users@lists.fedorahosted.org> wrote: > > > > > > We have a set of 3x freeIPA servers that have outdated (everything) in a > > development/test environment that need to be updated. > > > > > > It seems that 4.6.8-5.el7.centos.12 is the latest version available on > > CentOS 7? > > > > > > We are at on the 3 servers: > > > 4.5.4-10.el7.centos.4.4 > > > 4.6.4-10-el7.centos.6 > > > 4.6.4-10-el7.centos.6 > > > > > > For the two 4.6.4 installs, that seems relatively simple upgrade as we > > would only be going to a different dot release and a simple "yum update > > ipa-server" should handle this? Is there any advisement for/against doing a > > full "yum update" on the entire system to get everything updated? > > > > > > For the 4.5.4 system, is there much of a concern going straight from > > 4.5.4 to 4.6.8 straight? I assume the concern would be jumping major > > versions and going from say 4.5 to 4.9? > > > > > > My current plan is to stop at CentOS 7.9 and latest FreeIPA 4.6 release > > on CentOS 7.9. But for my own knowledge if I was going to 4.10 wouldn't the > > recommendation path to upgrade to 4.10, to install CentOS Stream 9 on a new > > server, enroll it, make 4.10 the master and then remove the CentOS 7 > > instances? > > > > > > > Assuming you can't have a 4th server, Is it possible for you to have only > > 2 replicas for some time? If so, you can remove the 4.5.4 server, fully > > (cleanly?) upgrade it, add it back, set it as CA master, and repeat the > > procedure with the other servers. > > > > As you are upgrading the whole OS, this would be more in line with the > > current recommendation (see > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/migrating_to_identity_management_on_rhel_8/migrate-7-to-8_migrating > > ). > > > > Rafael > > > > > -Kevin > > > > > > > > > ___ > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > > > To unsubscribe send an email to > > freeipa-users-le...@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.fedorahosted.org > > > > > Do not reply to spam, report it: > > https://pagure.io/fedora-infrastructure/new_issue > > > > > > > > -- > > Rafael Guterres Jeffman > > Senior Software Engineer > > FreeIPA - Red
[Freeipa-users] Re: ipa-replica-install fails when I use custom certificates
Bryan Fang via FreeIPA-users wrote: > Hi Rob and Flo, > thanks for your reply, yes I am using external CA certificate, we have > separate Apache server as proxy of ipa server, and we are using external CA > certificate for Apache server, version of ipa server is 4.6.8, and I don’t > know how to upgrade domain level to 1, I tried to manually set it to 1 but > failed with error message ‘server doesn’t support the domain level’, if I ant > to reuse existing ipa server, how can I promote it to be replica? Or would > you pls advise me how to rebuild all of deployment? Thanks a lot! IIRC Flo already suggested including the entire certificate chain within the PKCS#12 files you provide to ipa-replica-prepare. That may resolve the problem. We don't test nor recommend using a proxy in front of IPA. rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: Force LDAPS and 636 port
Greetings, Thanks a lot for your explanation. Based on your message and my humble research would it be safe to say that to enforce TLS connections with a specific ciphers to the default FreeIPA deployment one can do these: 1. Require secure bind nsslapd-require-secure-binds=on (will reject all the connections without STARTTLS) 2. Disabling Anonymous Binds nsslapd-allow-anonymous-access=rootdse (to allow read dir info) 3. Set nsSSL3Ciphers to ones we approve 4. Set sslVersionMin to the lower one we support I spoke to my security team and explained to them the situation with 389 and 636 ports. They agreed to comply with your advice but strictly told that it is mandatory to maintain secure communication using TLS and a certain number of ciphers they see as strong. Regards, Alex Ivanov On Tue, Jan 31, 2023 at 6:18 PM Alexander Bokovoy wrote: > On ti, 31 tammi 2023, Alex Ivanov via FreeIPA-users wrote: > >Greetings, > > > >I'm struggling to find a comprehensive guide on how to block LDAP and > >389 port on FreeIPA and force usage of LDAPS and 636 port for all > >clients and connections. I would really appreciate a link or a hint. > > There is no such guide because FreeIPA requires use of LDAP/389, both > TCP and UDP, same as with Active Directory. We enforce encrypted > connections within SASL GSSAPI-authenticated sessions. > > If you have requirements to close done port 389, well, tell those people > to go and learn how domain resolution protocols are done in Active > Directory and similar systems. > > LDAP use of port 636 is not really standardized (it was an RFC proposal > that expired and not made into RFC at all). All the manual work to make > it supported is not going to play well with the fact that Windows > systems still required to talk port 389 for general domain controller > discovery questions: > > https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/7fcdce70-5205-44d6-9c3a-260e616a2f04 > and then > https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/895a7744-aff3-4f64-bcfa-f8c05915d2e9 > > If you are using Kerberos and SASL GSSAPI or SASL GSS-SPNEGO (default > configuration for SSSD and RHEL IdM), none of disabling for LDAP 389 > port is needed. This is because RHEL version of CyrusSASL automatically > enables encryption and signing when Kerberos is in use with AES > encryption types. > > We use LDAP SASL GSSAPI/GSS-SPNEGO to actually authenticate to IPA and > AD LDAP resources. Due to how this is implemented in RHEL, such > connections are then encrypted. This works everywhere, for example, > there is no need to switch to port 3269 for Global Catalog traffic. > > From my email roughly three years ago, the same applies to any LDAP > traffic with SASL GSSAPI/GSS-SPNEGO authentication, not just port 389 > but 3268 as well: > > --- > We added two important fixes in RHEL 7.4-7.5 timeframe: > - RHEL 7.4: support GSS-SPNEGO in CyrusSASL, with cyrus-sasl-2.1.26-21 > or later installed > (https://bugzilla.redhat.com/show_bug.cgi?id=1421663), > > - RHEL 7.5: support autodiscovery of minimal SSF with > GSSAPI/GSS-SPNEGO, with cyrus-sasl-2.1.26-22 or later installed > (https://bugzilla.redhat.com/show_bug.cgi?id=1431586) > > These should be enough because SSSD uses LDAP with SASL based on > CyrusSASL library and negotiates GSSAPI/GSS-SPNEGO with sealing > (encryption) by default in all new RHEL 7/RHEL 8 deployments. > > > We keep getting these questions from the customers for SSSD accessing AD > LDAP all the time. Well, that was the case couple years ago, not > anymore, except your email today. > > If you want to see that the traffic is encrypted, try without > GSSAPI_* options in ldap.conf and I can see following with tshark in > LDAP communication after bind was successfully performed. This is > running 'ldapsearch -Y GSSAPI -h AD-DC -b $basedn cn=Administrator' > > Lightweight Directory Access Protocol > SASL Buffer Length: 127 > SASL Buffer > GSS-API Generic Security Service Application Program Interface > krb5_blob: 050406ff0262b065c0d8351b29fd1943<80> > krb5_tok_id: KRB_TOKEN_CFX_WRAP (0x0405) > krb5_cfx_flags: 0x06, AcceptorSubkey, Sealed > .1.. = AcceptorSubkey: Set > ..1. = Sealed: Set > ...0 = SendByAcceptor: Not set > > As you can see, we do send encrypted (Sealed bit) traffic. > > AD DCs respond with sealed traffic as well: > > Lightweight Directory Access Protocol > SASL Buffer Length: 127 > SASL Buffer > GSS-API Generic Security Service Application Program Interface > krb5_blob: 050406ff0262b065c0d8351b29fd1943<80> > krb5_tok_id: KRB_TOKEN_CFX_WRAP (0x0405) > krb5_cfx_flags: 0x06, AcceptorSubkey, Sealed > .1.. = AcceptorSubkey: Set > ..1. = Sealed: Set > ...0 = SendByAcceptor: Not set > > > This is due to use of Cyrus-SASL GSSAPI/GSS-SPNEGO plugin. In the
[Freeipa-users] Re: Certmonger and SAN fields
Alex Ivanov via FreeIPA-users wrote: > Greetings, > > I'm trying to use certmonger to automate certificate signing with FreeIPA. It > is working fine but it adds additional values to SAN for issued certificates > > Other Name: > Principal Name=HTTP/@ > Other Name: > 1.3.6.1.5.2.2= > > If I choose to generate certificates using openssl and manually sign them I > have no such issue > > I've found old post about that > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/2JOL7OAKZQXIZWIYBFNQJTXC4L2WPNAD/ > > Does this issue still persists or I've missed something? It is working as designed. What is the reason you don't need/want additional SAN associated with the issued certificate? rob ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Certmonger and SAN fields
Greetings, I'm trying to use certmonger to automate certificate signing with FreeIPA. It is working fine but it adds additional values to SAN for issued certificates Other Name: Principal Name=HTTP/@ Other Name: 1.3.6.1.5.2.2= If I choose to generate certificates using openssl and manually sign them I have no such issue I've found old post about that https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/2JOL7OAKZQXIZWIYBFNQJTXC4L2WPNAD/ Does this issue still persists or I've missed something? ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: Questions about /root/cacert.p12 file
Hi Rob, Thank you for the explanation. Makes sense. Kathy. On Tue, Feb 7, 2023 at 5:32 PM Rob Crittenden wrote: > Kathy Zhu via FreeIPA-users wrote: > > Hi Team, > > > > I like to understand more about the /root/cacert.p12 file in a self > > signed CA environment. Here are the questions: > > > > 1, could this file be located somewhere other than under /root? > > 2, what operations use this file instead of nssdb? In other words, if > > the /root/cacert.p12 file were not in place, what operations would fail? > > 3, any good readings to learn more? > > This is not operational. It is a backup of your CA keys in case > something catastrophic happens, created at time of initial server > installation. Depending IPA version you don't need it at all. Early > versions would use this file to prepare replicas. We ended up instead > calling PKCS12Export to generate a new one prior to replica creation. > > I don't think it is really used with domain-level 1 at all, so any > version released in the last 5 years or so. > > It is an artifact that comes out of the CA installation. It's in /root > to provide the best possible protection for the file. The default > /var/lib/pki/pki-tomcat/alias/ca_backup_keys.p12. We move it. > > You might find information about it in the RHCS documentation. > > rob > > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: Upgrade outdated FreeIPA sanity check
Thanks Rafael. I was hoping to do it in place if at all possible because where things get complicated is the 4.5.4 server is also the internal DNS server that everyone utilizes (we have multiple but people just use the 1 mainly). It really was their "main" server. I added the other two replicas a few years ago to make sure we had something. They contacted me and wanted help to upgrade everything so here I am. Making any modifications to it will probably make everything go heywire (or at least break DNS for everyone). That is unless I get it back immediately by 1. adding a 4th server 2. promoting the 4th server to master 3. decommission the 4.5.4 server 4. reassign the 4th server the same IP as the old 4.5.4 server? 5. upgrade rest of servers Any thoughts? recommendations? On Wed, Feb 8, 2023 at 5:43 AM Rafael Jeffman wrote: > > > On Tue, Feb 7, 2023 at 6:29 PM Kevin Vasko via FreeIPA-users < > freeipa-users@lists.fedorahosted.org> wrote: > > > > We have a set of 3x freeIPA servers that have outdated (everything) in a > development/test environment that need to be updated. > > > > It seems that 4.6.8-5.el7.centos.12 is the latest version available on > CentOS 7? > > > > We are at on the 3 servers: > > 4.5.4-10.el7.centos.4.4 > > 4.6.4-10-el7.centos.6 > > 4.6.4-10-el7.centos.6 > > > > For the two 4.6.4 installs, that seems relatively simple upgrade as we > would only be going to a different dot release and a simple "yum update > ipa-server" should handle this? Is there any advisement for/against doing a > full "yum update" on the entire system to get everything updated? > > > > For the 4.5.4 system, is there much of a concern going straight from > 4.5.4 to 4.6.8 straight? I assume the concern would be jumping major > versions and going from say 4.5 to 4.9? > > > > My current plan is to stop at CentOS 7.9 and latest FreeIPA 4.6 release > on CentOS 7.9. But for my own knowledge if I was going to 4.10 wouldn't the > recommendation path to upgrade to 4.10, to install CentOS Stream 9 on a new > server, enroll it, make 4.10 the master and then remove the CentOS 7 > instances? > > > > Assuming you can't have a 4th server, Is it possible for you to have only > 2 replicas for some time? If so, you can remove the 4.5.4 server, fully > (cleanly?) upgrade it, add it back, set it as CA master, and repeat the > procedure with the other servers. > > As you are upgrading the whole OS, this would be more in line with the > current recommendation (see > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/migrating_to_identity_management_on_rhel_8/migrate-7-to-8_migrating > ). > > Rafael > > > -Kevin > > > > > > ___ > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > > To unsubscribe send an email to > freeipa-users-le...@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.fedorahosted.org > > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > > > > -- > Rafael Guterres Jeffman > Senior Software Engineer > FreeIPA - Red Hat > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: How to lock a user after password expired for some period
Thank you. Yes, this is my needed solution. Also have to upgrade to version 4.9.10+. Regards, Lee ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: Upgrade outdated FreeIPA sanity check
On Tue, Feb 7, 2023 at 6:29 PM Kevin Vasko via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > > We have a set of 3x freeIPA servers that have outdated (everything) in a development/test environment that need to be updated. > > It seems that 4.6.8-5.el7.centos.12 is the latest version available on CentOS 7? > > We are at on the 3 servers: > 4.5.4-10.el7.centos.4.4 > 4.6.4-10-el7.centos.6 > 4.6.4-10-el7.centos.6 > > For the two 4.6.4 installs, that seems relatively simple upgrade as we would only be going to a different dot release and a simple "yum update ipa-server" should handle this? Is there any advisement for/against doing a full "yum update" on the entire system to get everything updated? > > For the 4.5.4 system, is there much of a concern going straight from 4.5.4 to 4.6.8 straight? I assume the concern would be jumping major versions and going from say 4.5 to 4.9? > > My current plan is to stop at CentOS 7.9 and latest FreeIPA 4.6 release on CentOS 7.9. But for my own knowledge if I was going to 4.10 wouldn't the recommendation path to upgrade to 4.10, to install CentOS Stream 9 on a new server, enroll it, make 4.10 the master and then remove the CentOS 7 instances? > Assuming you can't have a 4th server, Is it possible for you to have only 2 replicas for some time? If so, you can remove the 4.5.4 server, fully (cleanly?) upgrade it, add it back, set it as CA master, and repeat the procedure with the other servers. As you are upgrading the whole OS, this would be more in line with the current recommendation (see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/migrating_to_identity_management_on_rhel_8/migrate-7-to-8_migrating ). Rafael > -Kevin > > > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- Rafael Guterres Jeffman Senior Software Engineer FreeIPA - Red Hat ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: Issue with Login PIN Prompting with SSSD and krb5_child.
Am Wed, Feb 08, 2023 at 08:37:11AM - schrieb r0 nam1 via FreeIPA-users: > Uploaded logs that were created when logged in: > https://temp.sh/FwJrh/terminallogs.zip > (By 'tail -f' while logging in) Hi, it looks like you have added ipacertmapdata base mapping rule, but there is no user in IPA where you added the mapping data: (2023-02-08 0:27:03): [be[internal.my.domain]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(ipacertmapdata=X509:O=INTERNAL.MY.DOMAIN,CN=Certificate\20AuthorityO=INTERNAL.MY.DOMAIN,CN=user)(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0][cn=accounts,dc=internal,dc=my,dc=domain]. (2023-02-08 0:27:03): [be[internal.my.domain]] [sdap_search_user_process] (0x2000): Retrieved total 0 users based on this SSSD does not know which user is the owner of the Smartcard/certificate and falls back to password authentication. You can use 'ipa user-add-certmapdata' to add the needed data to an IPA user object. bye, Sumit > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Freeipa-users] Re: Issue with Login PIN Prompting with SSSD and krb5_child.
Uploaded logs that were created when logged in: https://temp.sh/FwJrh/terminallogs.zip (By 'tail -f' while logging in) ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
