Re: [Freeipa-users] PKI-CA fails to start (broken config after update?)
On 09/23/2014 03:59 AM, Ade Lee wrote: On Mon, 2014-09-22 at 13:39 -0600, swartz wrote: On 9/22/2014 9:14 AM, Ade Lee wrote: Another question - what is the output of ls -l /etc/pki-ca/CS.cfg ? ls -l /etc/pki-ca/CS.cfg -rw-r-. 1 pkiuser pkiuser 49196 Sep 19 11:29 /etc/pki-ca/CS.cfg In very rare cases, I've seen cases where the CS.cfg becomes truncated during an update. Unfortunately, we have not been able to reproduce the event. In later versions of dogtag, we make sure to save the CS.cfg just in case. Your instance sounds like a truncated CS.cfg instance, but the size is a lot larger than cases I've seen before, so I don't want to jump to that conclusion yet. JFTR, FreeIPA may have been involved as well, we had a related fix in FreeIPA 4.0.2: https://fedorahosted.org/freeipa/ticket/4166 If you scroll to the end of the CS.cfg, does it look like it has been truncated? If you have backups of the CS.cfg, that will help. Also, you could look for backups that we have created: find /var/lib/pki-ca -name CS.cfg* find /var/log -name CS.cfg* Also, do you have a replica CA? Ade I know that I did NOT change the configs myself. But something certainly did during 'yum update'. There are no .rpmsave or .rpmnew files that would typically be created if configs are properly marked in RPM spec file. There are two other files that exist though: -rw-r-. 1 pkiuser pkiuser 65869 Sep 19 11:30 CS.cfg.in.p21 -rw-rw. 1 pkiuser pkiuser 65955 Sep 5 2013 CS.cfg.in.p33 However, they are not usable either in place of current CS.cfg. The above files are templates only. They are modified during instance configuration. There have been no updates recently on rhel 6 to the pki packages. There has, however, been an update to tomcat - which broke dogtag startups. What version of tomcat6 is on your system? rpm -qa tomcat6 tomcat6-6.0.24-78.el6_5.noarch This tomcat version should still be a working one. The tomcat6 then broke things has not made it out yet, having been discovered in QE testing. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Announcing bind-dyndb-ldap version 6.0
The FreeIPA team is proud to announce bind-dyndb-ldap version 6.0. It can be downloaded from https://fedorahosted.org/released/bind-dyndb-ldap/ The new version has also been built for Fedora 21+ and and is on its way to updates-testing: https://admin.fedoraproject.org/updates/bind-dyndb-ldap-6.0-1.fc21 This version is also available from FreeIPA COPR repo: http://copr.fedoraproject.org/coprs/mkosek/freeipa/ 6.0 [1] idnsZoneActive attribute is supported again and zones can be activated and deactivated at run-time. https://fedorahosted.org/bind-dyndb-ldap/ticket/127 == Upgrading == A server can be upgraded by installing updated RPM. BIND has to be restarted manually after the RPM installation. Downgrading back to any 5.x version is supported if idnsZoneActive is always set to TRUE. == Feedback == Please provide comments, report bugs and send any other feedback via the freeipa-users mailing list: http://www.redhat.com/mailman/listinfo/freeipa-users -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] syslog
hi i have configured ipa (ipa on centos 6.5) and configure rsyslog for send log to syslog server (juniper strm) in strm get error unknown generic log event or log linux (on server install ipa client) but with another server linux not problem -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] What should we do with upstream guide?
Hello everyone! It's been over a year now since we announced [1] that the Technical Writer working on FreeIPA upstream guide [2] can no longer maintain the upstream version of it. FreeIPA project developers wanted to carry the torch and forked the outdated documentation in a new repository [3] and started the work on reviving it again [4][5]. Unfortunately, over the past year it became apparent that despite several brave contributors (special thanks to Gabe Alford and Martin Basti) helping with the guide, the project simply does not have resources to develop both FreeIPA and comprehensive documentation for it. The current FreeIPA guide is already way behind the RHEL-7 downstream guides [6][7] maintained by a new Technical Writer. In addition, old Fedora released documentation often pops up and clobbers FreeIPA upstream documentation in search engine results. This needs to change so that our users are not confused with obsolete information. Writing documentation is enormous task in itself. Currently, until a team of upstream Technical Writers joins the project to contribute alongside the developers the only viable option is to stop maintaining and reviving the upstream guide and keep only 2 main sources of documentation - design documents and articles of FreeIPA.org community wiki, and downstream documentation, from which the RHEL one [6][7] is the most complete. Upstream documentation tickets would be closed or transferred into the downstream doc Bugzillas, existing patches in [3] will be merged with the downstream RHEL documentation effort. This is the proposal. What do you think? Is it a reasonable move? Does anyone have time to be an upstream technical writer and carry the torch or should we move on with this plan? A sustainable documentation effort is needed and FreeIPA project is very much open to long term contributions. We are looking forward to your feedback, Your FreeIPA developers. [1] https://www.redhat.com/archives/freeipa-users/2013-August/msg00044.html [2] http://docs.fedoraproject.org/en-US/Fedora/18/html-single/FreeIPA_Guide/index.html [3] https://git.fedorahosted.org/cgit/freeipa-docs.git [4] https://fedorahosted.org/freeipa/milestone/Revive%20FreeIPA%20guide [5] https://fedorahosted.org/freeipa/milestone/FreeIPA%203.x%20Documentation [6] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html [7] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/index.html [8] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/ln-idp9643248.html -- Martin Kosek mko...@redhat.com Supervisor, Software Engineering - Identity Management Team Red Hat Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] weak and null ciphers detected on ldap ports
On 09/22/2014 10:07 PM, Nathan Kinder wrote: On 09/22/2014 05:03 AM, Murty, Ajeet (US - Arlington) wrote: Security scan of FreeIPA server ports uncovered weak, medium and null ciphers on port 389 and 636. We are running ‘ipa-server-3.0.0-37.el6.i686’. How can I disable/remove these ciphers in my existing setup? This has recently been worked on in this 389-ds-base ticket: https://fedorahosted.org/389/ticket/47838 As mentioned in the initial description of that ticket, you can configure the allowed ciphers in the cn=config entry in 389-ds-base. You can edit this over LDAP, or by stopping 389-ds-base and editing /etc/dirsrv/slapd-REALM/dse.ldif. Thanks, -NGK You can also check the FreeIPA counterpart: https://fedorahosted.org/freeipa/ticket/4395 This issue is fixed in FreeIPA 4.0.3 (available in Copr build and Fedora 21+), we would very much welcome if you can verify that this setup works for you! Thanks, Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Compat tree and group membership in a trust environment
Querying for group membership in the compat tree within a trust environment seems to be rather flaky: * userA and userB are members of admins@ad. admins@ad is member of internet_access@ad * internet_access@ad is member of internet_access_external@ad * internet_access_external@ad is member of internet_access@ad * I restart ipa and clear sssd cache on the master to start with a clean compat tree * searching for ((objectClass=posixGroup)(memberUid=userA@ad)) returns that he is a member of internet_access@ipa (expected result) * searching for ((objectClass=posixGroup)(memberUid=userB@ad)) doesn't return him as a member of internet_access@ipa (unexpected) If I restart ipa and clean sssd cache on the master and query first for userB he gets the correct memberships, queries for subsequent users (userA, userC) won't show if they are members of ipa groups. IPA version is 3.3.3-28.el7 on Centos 7, AD is Server 2008. Should I file a bug? -- Loris Santamaria linux user #70506 xmpp:lo...@lgs.com.ve Links Global Services, C.A.http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:1...@lgs.com.ve If I'd asked my customers what they wanted, they'd have said a faster horse - Henry Ford smime.p7s Description: S/MIME cryptographic signature -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Squid negotiate auth and trust relationship
Hi, I'm setting up a squid proxy in a environment with a trust relationship between IPA and AD. The machine where squid is running belongs to the IPA domain, users may belong to AD or to IPA and in each one of the domains there are groups that define the level of internet access of their members. For simplicity's sake, let's say that there is only one group in each domain called internet_access. Its member should be granted permission by squid. In IPA I created an external group called internet_access_ad, whose member is internet_acc...@ad.domain.com, so if the user is a member of internet_access in AD it should be a member of internet_access in IPA, thanks to the trust relationship. The authentication part works beautifully, IPA and AD users are recognized by the squid proxy via negotiate auth, but the authorization part is another story. Since the remote user hasn't logged in vía console or ssh on the server where squid is running, SSSD ignores its group membership, so one can't use squid's pam_group helper to determine if the user is in the internet_acc...@ipa.domain.com group. Trying to lookup for membership via ldap in the compat tree doesn't really work (see my previous mail on the subject). Also, it won't work when the realm name is in upper case, although this should be really easy to solve in the squid helper. For the time being I will resort to make two ldap queries, one on IPA and one on AD, but it seems to me that the proper way to go would be to decode the PAC and get authorization info from there, or have a way to query SSSD for complete group membership of a user even if he or she hasn't logged in on a server. How could SSSD/IPA could help to solve this fairly common need (querying user membership from an app)? -- Loris Santamaria linux user #70506 xmpp:lo...@lgs.com.ve Links Global Services, C.A.http://www.lgs.com.ve Tel: 0286 952.06.87 Cel: 0414 095.00.10 sip:1...@lgs.com.ve If I'd asked my customers what they wanted, they'd have said a faster horse - Henry Ford smime.p7s Description: S/MIME cryptographic signature -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Compat tree and group membership in a trust environment
On Tue, Sep 23, 2014 at 11:05:31AM -0430, Loris Santamaria wrote: Querying for group membership in the compat tree within a trust environment seems to be rather flaky: * userA and userB are members of admins@ad. admins@ad is member of internet_access@ad * internet_access@ad is member of internet_access_external@ad * internet_access_external@ad is member of internet_access@ad * I restart ipa and clear sssd cache on the master to start with a clean compat tree * searching for ((objectClass=posixGroup)(memberUid=userA@ad)) returns that he is a member of internet_access@ipa (expected result) * searching for ((objectClass=posixGroup)(memberUid=userB@ad)) doesn't return him as a member of internet_access@ipa (unexpected) If I restart ipa and clean sssd cache on the master and query first for userB he gets the correct memberships, queries for subsequent users (userA, userC) won't show if they are members of ipa groups. Can you check the logs first for a sign of any sssd problems? Recently we've troubleshooted another setup with a customer who saw sssd crashes on the server itself when a group was requested by SID, I wonder if this might be the same problem. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Compat tree and group membership in a trust environment
On Tue, 23 Sep 2014, Loris Santamaria wrote: Querying for group membership in the compat tree within a trust environment seems to be rather flaky: * userA and userB are members of admins@ad. admins@ad is member of internet_access@ad * internet_access@ad is member of internet_access_external@ad * internet_access_external@ad is member of internet_access@ad * I restart ipa and clear sssd cache on the master to start with a clean compat tree * searching for ((objectClass=posixGroup)(memberUid=userA@ad)) returns that he is a member of internet_access@ipa (expected result) * searching for ((objectClass=posixGroup)(memberUid=userB@ad)) doesn't return him as a member of internet_access@ipa (unexpected) slapi-nis doesn't fully support the latter case yet, it is known issue, though in the https://fedorahosted.org/freeipa/ticket/4403 it is manifested a bit differently. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Client Certificate
Yes Dmitri these two hints would definitely help, the servers are not 4.x yet though. On 19 September 2014 23:14, Dmitri Pal d...@redhat.com wrote: On 09/19/2014 04:03 PM, Walid wrote: Thank you all, will investigate the requirements of host keytabs, and if there is a way around it by having it shared but secure for our context. Couple hints. 1. If you have a keytab stashed and the system was rebuilt you can now rerun ipa-client-install using this keytab to get a new one and configure the client system. It can run and then die but if you store the keytab after running ipa-client-install you would be able to revive it next time 2. In 4.1 you will be able to retrieve same keytab using ipa-getkeytab command. It is implemented to allow clusters that have to share the same key but it might be applicable to your use case too. Thanks Dmitri On 18 September 2014 23:04, Dmitri Pal d...@redhat.com wrote: On 09/18/2014 10:12 AM, Walid A. Shaari wrote: Hi, we are going to have a use case of diskless HPC clients that will use the IPA for lookups, I was wondering if i can get rid of the state-fulness of the client configuration as much as possible as it is more of a cattle than pets use case. that is i do not need to know that the client is part of the domain, no need to enroll a node with a certificate. and services will be mostly hpc mpi and ssh, not required to have an SSL certificate for secure communication. is it possible to get rid of the client certificate and the requirements for clients to enroll? or there are other uses for the certificate that i am not aware of ? regards Walid I think the main problem is making sure that the client can connect to IPA server. You can elect to not use ipa-client and just copy configuration files. The problem is that SSSD requires some type of the authentication to get to IPA as a host to do the lookups. So this connection must be authenticated. Since you want it to be stateless you do not want to manage keys or certs the only option (which I really do not like) is to use bind password in a file for LDAP connection. You would probably use the same unprivileged account for this bind. However when we get to 4.x you would need to adjust permissions on the server side to make sure that proper read permissions are granted. Having a password in a file is a security risk so make sure it is not leaked. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] Disable Anonymous LDAP another way...
Hi all, I have seen the documentation on how to disable anonymous access *completely* at http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html However, I think that those base rootdse queries are probably important. I originally thought they only happened when running ipa-client-install but some quick tailing of the access log indicates to me that they happen a lot. So, instead of flipping the big switch in cn=config, has anyone considered just removing anonymous access to the *directory* data like: # Remove Anonymous Access to main directory dn: dc=example,dc=com changetype: modify delete: aci aci: (target != ldap:///idnsname=*,cn=dns,dc=example,dc=com;)(targetatt r != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword | | passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutg oing || ipaNTTrustAuthIncoming)(version 3.0; acl Enable Anonymous access; allow (read, search, compare) userdn = ldap:///anyone;;) Would that work without breaking things? Do we have any information on what broken systems require anonymous LDAP binds and which ones do not? Thanks in advance, Tommy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] PKI-CA fails to start (broken config after update?)
On 9/22/2014 7:59 PM, Ade Lee wrote: If you scroll to the end of the CS.cfg, does it look like it has been truncated? I'd have to say no. It doesn't look truncated to me. At least there are no obvious signs. But then again I don't know everything that is suppose to be there. I know that the line starting with pkicreate.unsecure_port= isn't there, that's for sure. Hence why init script fails to start PKI-CA. If you have backups of the CS.cfg, that will help. Also, you could look for backups that we have created: Sadly there were no backups. This was a test/dev VM with no backup policy. find /var/lib/pki-ca -name CS.cfg* find /var/log -name CS.cfg* I've replied to you directly with all CS.cfg* files I could find. Most appear to be templates and not backups as per your message. Also, do you have a replica CA? Yes and no. The master was originally configured with a replica but the test replica VM was not used after that and was shutdown and removed. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] PKI-CA fails to start (broken config after update?)
On 9/22/2014 7:59 PM, Ade Lee wrote: If you scroll to the end of the CS.cfg, does it look like it has been truncated? I'd have to say no. It doesn't look truncated to me. At least there are no obvious signs. But then again I don't know everything that is suppose to be there. I know that the line starting with pkicreate.unsecure_port= isn't there, that's for sure. Hence why init script fails to start PKI-CA. If you have backups of the CS.cfg, that will help. Also, you could look for backups that we have created: Sadly there were no backups. This was a test/dev VM with no backup policy. find /var/lib/pki-ca -name CS.cfg* find /var/log -name CS.cfg* I've replied to you directly with all CS.cfg* files I could find. Most appear to be templates and not backups as per your message. Also, do you have a replica CA? Yes and no. The master was originally configured with a replica but the test replica VM was not used after that and was shutdown and removed. PS. I replied to the wrong email. Ooops, sorry. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Disable Anonymous LDAP another way...
DISREGARD! Sorry all, do not actually try my query, it makes authentication not work at least on CentOS6. Here is the doc I actually read the first time: http://docs.fedoraproject.org/en-US/Fedora/15/html/FreeIPA_Guide/disabling-anon-binds.html (google search led me here) ... which says to turn it off, while the one I linked above: http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html says to set it to rootdse which allows the necessary access for detecting configuration, but blocks access to directory data. I just mis-read it on the F18 docs. Sorry for the noise :) On Tue, Sep 23, 2014 at 5:11 PM, Tommy McNeely tommythe...@gmail.com wrote: Hi all, I have seen the documentation on how to disable anonymous access *completely* at http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/disabling-anon-binds.html However, I think that those base rootdse queries are probably important. I originally thought they only happened when running ipa-client-install but some quick tailing of the access log indicates to me that they happen a lot. So, instead of flipping the big switch in cn=config, has anyone considered just removing anonymous access to the *directory* data like: # Remove Anonymous Access to main directory dn: dc=example,dc=com changetype: modify delete: aci aci: (target != ldap:///idnsname=*,cn=dns,dc=example,dc=com;)(targetatt r != userPassword || krbPrincipalKey || sambaLMPassword || sambaNTPassword | | passwordHistory || krbMKey || userPKCS12 || ipaNTHash || ipaNTTrustAuthOutg oing || ipaNTTrustAuthIncoming)(version 3.0; acl Enable Anonymous access; allow (read, search, compare) userdn = ldap:///anyone;;) Would that work without breaking things? Do we have any information on what broken systems require anonymous LDAP binds and which ones do not? Thanks in advance, Tommy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Squid negotiate auth and trust relationship
On 09/23/2014 11:54 AM, Loris Santamaria wrote: Hi, I'm setting up a squid proxy in a environment with a trust relationship between IPA and AD. The machine where squid is running belongs to the IPA domain, users may belong to AD or to IPA and in each one of the domains there are groups that define the level of internet access of their members. For simplicity's sake, let's say that there is only one group in each domain called internet_access. Its member should be granted permission by squid. In IPA I created an external group called internet_access_ad, whose member is internet_acc...@ad.domain.com, so if the user is a member of internet_access in AD it should be a member of internet_access in IPA, thanks to the trust relationship. The authentication part works beautifully, IPA and AD users are recognized by the squid proxy via negotiate auth, but the authorization part is another story. Since the remote user hasn't logged in vía console or ssh on the server where squid is running, SSSD ignores its group membership, so one can't use squid's pam_group helper to determine if the user is in the internet_acc...@ipa.domain.com group. Trying to lookup for membership via ldap in the compat tree doesn't really work (see my previous mail on the subject). Also, it won't work when the realm name is in upper case, although this should be really easy to solve in the squid helper. For the time being I will resort to make two ldap queries, one on IPA and one on AD, but it seems to me that the proper way to go would be to decode the PAC and get authorization info from there, or have a way to query SSSD for complete group membership of a user even if he or she hasn't logged in on a server. How could SSSD/IPA could help to solve this fairly common need (querying user membership from an app)? I think this is the issue that you are describing. Patches are on the list and targeting 4.1.x and 1.12.x https://fedorahosted.org/freeipa/ticket/4031 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] problem with log in ipa
hi i have configured ipa (ipa on centos 6.5) and configure rsyslog for send log to syslog server (juniper strm) in strm get error unknown generic log event (log's ipa clients ) but with another server linux not problem -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
