Re: [Freeipa-users] Problems with failed upgrade: groups are not created
Thanks for the reply Martin. Turns out that there was no problem at all, a minor configuration mistake (nested a group inside the wrong parent) led us down a rabbit hole. Our failed upgrade happened on the same day our 1000th group was created. Using the LDAP browser plugin for Eclipse the default search query limit is 1000… It took a while to work that out, needless to say we all feel a little silly and a little wiser now :) Will Sheldon On May 14, 2015 at 1:44:15 AM, Martin Basti (mba...@redhat.com) wrote: On 14/05/15 01:50, Will Sheldon wrote: Hello everyone :) We are seeing some strange behavior (created groups don't exist) and I really hope someone can lend some advice... We installed v 3.0 some time ago, and tried an upgrade to 3.3 which was aborted before completion, however I believe the schema was updated. Recently we attempted to upgrade to 4.1, but encountered some issues with the upgrade; replication failed : from the install log (before schema update, so server was running 3.3 schema): === Done configuring ipa-otpd. Applying LDAP updates ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure attribute cn not allowed === After that we tried updating the schema, and we now get this error (we have log file captures for this): === [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 131 seconds elapsed Update in progress yet not in progress [vanipa.foo.com] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. which seems to be referring to this bit of the log: === 2015-04-21T19:18:48Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) === Since then we have a somewhat strange issue where new groups that are added using the web interface and ipa CLI command interface are created in the compat tree, but not in the cn=hostgroups,cn=accounts tree, even though ADD operations appear to complete successfully (slapd log output below) === [13/May/2015:23:13:58 +] conn=7120402 op=4 ADD dn=cn=p-test-100,cn=hostgroups,cn=accounts,dc=foo,dc=com [13/May/2015:23:13:58 +] conn=2616653 op=3660217 SRCH base=idnsName=net,idnsname=bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660217 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660218 SRCH base=idnsName=bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660218 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660219 SRCH base=idnsName=vanzbx.bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660219 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660220 SRCH base=idnsName=net,idnsname=bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660220 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660221 SRCH base=idnsName=bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660221 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660222 SRCH base=idnsName=vanzbx.bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660222 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=7120402 op=4 RESULT err=0 tag=105 nentries=0 etime=0 csn=5553e3f800010004 === Which is consistent with the slapd log during the upgrade: [21/Apr/2015:19:18:43 +] NSACLPlugin - The ACL target cn=hr,cn=groups,cn=accounts,dc=foo,dc=com does not exist -- Kind regards, Will Sheldon Hello, can you find in ipaserver-install.log more details about this error? ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERROR Add failure attribute cn not allowed Martin -- Martin Basti -- 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] Problems with failed upgrade: groups are not created
Hello everyone :) We are seeing some strange behavior (created groups don't exist) and I really hope someone can lend some advice... We installed v 3.0 some time ago, and tried an upgrade to 3.3 which was aborted before completion, however I believe the schema was updated. Recently we attempted to upgrade to 4.1, but encountered some issues with the upgrade; replication failed : from the install log (before schema update, so server was running 3.3 schema): === Done configuring ipa-otpd. Applying LDAP updates ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERRORAdd failure attribute cn not allowed === After that we tried updating the schema, and we now get this error (we have log file captures for this): === [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 131 seconds elapsed Update in progress yet not in progress [vanipa.foo.com] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. which seems to be referring to this bit of the log: === 2015-04-21T19:18:48Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 382, in start_creation run_step(full_msg, method) === Since then we have a somewhat strange issue where new groups that are added using the web interface and ipa CLI command interface are created in the compat tree, but not in the cn=hostgroups,cn=accounts tree, even though ADD operations appear to complete successfully (slapd log output below) === [13/May/2015:23:13:58 +] conn=7120402 op=4 ADD dn=cn=p-test-100,cn=hostgroups,cn=accounts,dc=foo,dc=com [13/May/2015:23:13:58 +] conn=2616653 op=3660217 SRCH base=idnsName=net,idnsname=bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660217 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660218 SRCH base=idnsName= bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660218 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660219 SRCH base=idnsName= vanzbx.bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660219 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660220 SRCH base=idnsName=net,idnsname=bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660220 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660221 SRCH base=idnsName= bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660221 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=2616653 op=3660222 SRCH base=idnsName= vanzbx.bar.net,idnsname=bar.net,cn=dns,dc=foo,dc=com scope=0 filter=(objectClass=idnsRecord) attrs=ALL [13/May/2015:23:13:58 +] conn=2616653 op=3660222 RESULT err=32 tag=101 nentries=0 etime=0 [13/May/2015:23:13:58 +] conn=7120402 op=4 RESULT err=0 tag=105 nentries=0 etime=0 csn=5553e3f800010004 === Which is consistent with the slapd log during the upgrade: [21/Apr/2015:19:18:43 +] NSACLPlugin - The ACL target cn=hr,cn=groups,cn=accounts,dc=foo,dc=com does not exist -- Kind regards, Will Sheldon -- 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] IPA and geographically distributed masters
We have multiple distributed replicas running in the following locations: East coast AMER West coast AMER London EMEA and have had no issues with replication or performance. (max ping is about 120ms) Will Sheldon On April 1, 2015 at 3:50:23 PM, Steven Jones (steven.jo...@vuw.ac.nz) wrote: Hi, Would IPA have issues if one master is one one side of the Pacific (New Zealand) and another in the USA? regards Steven J -- 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 -- 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] Debian 7.0.8 and REHL IPA
There is a ppa for ubuntu: https://code.launchpad.net/~freeipa/+archive/ubuntu/ppa and packages in the deb archives: https://packages.qa.debian.org/f/freeipa.html I’ve had mixed results using them, there seem to be frequent regressions so having a canary machine / cluster is essential. The install script also had some issues, but I believe it’s better now? last time I tried was about 12 months ago. Will. On March 24, 2015 at 2:29:09 PM, Steven Jones (steven.jo...@vuw.ac.nz) wrote: Hi, Anyone have experience with running the sssd client (I assume its available) on Debian 7.0.8 against a RH IPA setup? Is it painless long term or best avoided? regards Steven -- 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 -- 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] 3.0.0-42 Replication issue after Centos6.5-6.6 upgrade
No, not resolved yet I did test with GSSAPI (-Y) and like you it worked. :( Will Sheldon On November 18, 2014 at 8:37:10 AM, dbisc...@hrz.uni-kassel.de (dbisc...@hrz.uni-kassel.de) wrote: Hi, On Fri, 7 Nov 2014, Dmitri Pal wrote: On 11/07/2014 01:24 AM, Will Sheldon wrote: On November 6, 2014 at 10:07:54 PM, Dmitri Pal (d...@redhat.com mailto:d...@redhat.com) wrote: On 11/07/2014 12:18 AM, Will Sheldon wrote: On the whole we are loving FreeIPA, Many thanks and much respect to all involved, we’ve had a great 12-18 months hassle free use out of it - it is a fantastically stable trouble free solution… however now we’ve run into a small issue we (as mere mortals) are finding it hard to resolve :-/ We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything seems to go well, but one server is behaving oddly. It’s likely not an IPA issue, it also reset it’s hostname somehow after the upgrade (it’s an image in an openstack environment) If anyone has any pointers as to how to debug I’d be hugely appreciative :) Two servers, server1.domain.com and server2.domain.com Server1 can’t push data to server2, there are updates and new records on server1 that do not exist on server2. from the logs on server1: [07/Nov/2014:01:33:42 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) [07/Nov/2014:01:33:47 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Replication bind with GSSAPI auth resumed [07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Warning: unable to replicate schema: rc=2 [07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. Try to see a) Server 1 properly resolves server 2 b) You can connect from server 1 to server 2 using ldapsearch c) your firewall has proper ports open d) dirserver on server 2 is actually running All seems working: [root@server1 ~]# ldapsearch -x -H ldap://server2.domain.com -s base -b '' namingContexts Can you try kinit admin and then use kerberos GSSAPI to connect, i.e. -Y switch? is this resolved? I observe it on my systems, too. Exact same symptoms. ldapsearch with -Y GSSAPI works. Did you find anything in the server2 logs? On my server2, I see sasl_io_recv failed to decode packet for connection #. Could there be something wrong with default buffer sizes as described in https://bugzilla.redhat.com/show_bug.cgi?id=953653 I have nsslapd-sasl-max-buffer-size: 65536 on both machines, but my database is rather small: ~30 users, 10 hosts and services. # extended LDIF # # LDAPv3 # base with scope baseObject # filter: (objectclass=*) # requesting: namingContexts # # dn: namingContexts: dc=domain,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@server1 ~]# And: [root@server2 ~]# /etc/init.d/dirsrv status dirsrv DOMAIN-COM (pid 1009) is running... dirsrv PKI-IPA (pid 1083) is running... [root@server2 ~]# Check logs on server 2 to see whether it actually sees an attempt to connect, I suspect not, so it is most likely a DNS/FW issue or dir server is not running on 2. and the servers: [root@server1 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server2.domain.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: 2014-11-07 01:35:58+00:00 [root@server1 ~]# [root@server2 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server1.domain.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-11-07 01:35:43+00:00 [root@server2 ~]# Mit freundlichen Gruessen/With best regards, --Daniel. -- 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-- 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] 3.0.0-42 Replication issue after Centos6.5-6.6 upgrade
Hello all :) On the whole we are loving FreeIPA, Many thanks and much respect to all involved, we’ve had a great 12-18 months hassle free use out of it - it is a fantastically stable trouble free solution… however now we’ve run into a small issue we (as mere mortals) are finding it hard to resolve :-/ We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything seems to go well, but one server is behaving oddly. It’s likely not an IPA issue, it also reset it’s hostname somehow after the upgrade (it’s an image in an openstack environment) If anyone has any pointers as to how to debug I’d be hugely appreciative :) Two servers, server1.domain.com and server2.domain.com Server1 can’t push data to server2, there are updates and new records on server1 that do not exist on server2. from the logs on server1: [07/Nov/2014:01:33:42 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) [07/Nov/2014:01:33:47 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Replication bind with GSSAPI auth resumed [07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Warning: unable to replicate schema: rc=2 [07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. and the servers: [root@server1 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server2.domain.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: 2014-11-07 01:35:58+00:00 [root@server1 ~]# [root@server2 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server1.domain.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-11-07 01:35:43+00:00 [root@server2 ~]# Will Sheldon -- 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] 3.0.0-42 Replication issue after Centos6.5-6.6 upgrade
On November 6, 2014 at 10:07:54 PM, Dmitri Pal (d...@redhat.com) wrote: On 11/07/2014 12:18 AM, Will Sheldon wrote: Hello all :) On the whole we are loving FreeIPA, Many thanks and much respect to all involved, we’ve had a great 12-18 months hassle free use out of it - it is a fantastically stable trouble free solution… however now we’ve run into a small issue we (as mere mortals) are finding it hard to resolve :-/ We upgraded our ipa servers (3.0.0-42) to Centos 6.6. everything seems to go well, but one server is behaving oddly. It’s likely not an IPA issue, it also reset it’s hostname somehow after the upgrade (it’s an image in an openstack environment) If anyone has any pointers as to how to debug I’d be hugely appreciative :) Two servers, server1.domain.com and server2.domain.com Server1 can’t push data to server2, there are updates and new records on server1 that do not exist on server2. from the logs on server1: [07/Nov/2014:01:33:42 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Warning: unable to send endReplication extended operation (Can't contact LDAP server) [07/Nov/2014:01:33:47 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Replication bind with GSSAPI auth resumed [07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Warning: unable to replicate schema: rc=2 [07/Nov/2014:01:33:48 +] NSMMReplicationPlugin - agmt=cn=meToserver2.domain.com (server2:389): Consumer failed to replay change (uniqueid (null), CSN (null)): Can't contact LDAP server(-1). Will retry later. Try to see a) Server 1 properly resolves server 2 b) You can connect from server 1 to server 2 using ldapsearch c) your firewall has proper ports open d) dirserver on server 2 is actually running All seems working: [root@server1 ~]# ldapsearch -x -H ldap://server2.domain.com -s base -b '' namingContexts # extended LDIF # # LDAPv3 # base with scope baseObject # filter: (objectclass=*) # requesting: namingContexts # # dn: namingContexts: dc=domain,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 [root@server1 ~]# And: [root@server2 ~]# /etc/init.d/dirsrv status dirsrv DOMAIN-COM (pid 1009) is running... dirsrv PKI-IPA (pid 1083) is running... [root@server2 ~]# Check logs on server 2 to see whether it actually sees an attempt to connect, I suspect not, so it is most likely a DNS/FW issue or dir server is not running on 2. and the servers: [root@server1 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server2.domain.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update started last update ended: 2014-11-07 01:35:58+00:00 [root@server1 ~]# [root@server2 ~]# ipa-replica-manage list -v `hostname` Directory Manager password: server1.domain.com: replica last init status: None last init ended: None last update status: 0 Replica acquired successfully: Incremental update succeeded last update ended: 2014-11-07 01:35:43+00:00 [root@server2 ~]# Will Sheldon -- 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-- 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] DNS: Possible to set a CNAME for bare domain?
Hello everyone : ) Is it possible to configure a CNAME for a bare domain with freeIPA? We would like to move our site over to an Amazon ELB, but to do so we have to point our domain (foo.com, not www.foo.com) at an was A record with a CNAME (something like .eu-west-1.elb.amazonaws.com) This is technically possible, but IPA complains: invalid 'cnamerecord': CNAME record is not allowed to coexist with any other records except PTR I’m guessing this is because of the @ NS record. Is there any way to override this behaviour? Can I make manual modifications to the zone file? Will Sheldon -- 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] DNS: Possible to set a CNAME for bare domain?
Thanks Michael, it seems you are correct. I knew I’d seen it done though - turns out that if you use route53 for your DNS amazon has a way of making it work with a virtual record type called an alias. I guess we’ll just have to use route53. At least alias lookups are free. On October 4, 2014 at 10:20:43 AM, Michael Lasevich (mlasev...@gmail.com) wrote: You cannot have cname for a bare domain in IPA or in any DNS service, it violates DNS rfc's. On Oct 4, 2014 10:19 AM, Will Sheldon m...@willsheldon.com wrote: Hello everyone : ) Is it possible to configure a CNAME for a bare domain with freeIPA? We would like to move our site over to an Amazon ELB, but to do so we have to point our domain (foo.com, not www.foo.com) at an was A record with a CNAME (something like .eu-west-1.elb.amazonaws.com) This is technically possible, but IPA complains: invalid 'cnamerecord': CNAME record is not allowed to coexist with any other records except PTR I’m guessing this is because of the @ NS record. Is there any way to override this behaviour? Can I make manual modifications to the zone file? Will Sheldon -- 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 -- 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] Password expiration dates are different when being resetted by the (primary) admin and a different admin
1a) has come up before: https://www.redhat.com/archives/freeipa-users/2014-February/msg00313.html 1b) We handled this by setting the expire lifetime to a very large value (20 years) for members of a certain group. 2) I’m not sure. Kind regards, Will Sheldon +1.778-689-1244 On August 28, 2014 at 7:26:03 AM, Zip Ly (zip...@gmail.com) wrote: Hi, I'm trying to change a user password without reset. If I use the (primary) admin to change the password then it doesn't need a password reset, because the expire lifetime is 90 days. But if I create a second admin, then every password change made by the second admin needs a password reset, because the password is expired immediately. 1a) Does anyone knows how I can change the policy/privilege of the second admin so every password change doesn't require a reset? 1b) and is it possible to set a different expire lifetime like zero for unlimited lifetime? It's almost the same bugreport as https://fedorahosted.org/freeipa/ticket/2795 but the difference is there should be 2 policies: one for changing your own password and another for resetting other users password. 2) Are there more differences in policies between the first (primary) admin and the second admin you just created? Kind regards, Zip -- 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-- 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] ipa-server-install + NATTED interface question
I had this issue as well. It would be good to add a `curl icanhazip.com` check to the script to allow for 1:1 nat in places like AWS. I successfully worked around the issue by allocating the external IP to an internal sub interface during the install: so run: ifconfig eth0:0 192.168.10.10 netmask 255.255.255.0 up then try the install again. Kind regards, Will Sheldon On Monday, March 31, 2014 at 11:59 AM, The Dude wrote: Hi all; avid user of both FreeIPA and IPA for a few years now. I have a unique situation that I hope someone can provide some insight, or help with. I am presented a private, and public (floating) IP after RX a VM from my IaaS provider. The 'public' IP is NATted, and not visible from w/in the VM, but is reachable outside of the VM. In other words, if you were to do an 'ip a': eth0 would return the private IP. 11.11.11.11 (private) 192.168.10.10 (public) Because the installer only sees the 11.11.11.11 address, it bombs saying that I can't use that public IP (being obfuscated by NAT). So, my question is: if I have to use the private IP for installs, what configs should I edit to make Apache/TC respond to the public IP as requests come into it? I have already modified the conf/server.xml file, and added an 'address' filed/property. Apache might need some mods, I headed over to the httpd.conf file and didn't see anything out of the ordinary (except there are 0 VirtualServer entries..) Ideas? Michael J. McConachie | keys.fedoraproject.org (http://keys.fedoraproject.org) | PubKey: 0xEDE583C4 NOTE: The information included and/or attached in this electronic mail transmission may contain confidential or privileged information and is intended solely for the addressee(s). Any unauthorized disclosure, reproduction, distribution or the taking of action in reliance on the contents of the information are strictly prohibited. If you have received the message in error, please notify the sender by reply transmission and delete the message without copying, disclosing or forwarding. ___ Freeipa-users mailing list Freeipa-users@redhat.com (mailto:Freeipa-users@redhat.com) https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Win7 machine occasionally not able to lookup ipa hosts
What is the difference in the output of ipconfig /all” before and after the ipconfig /renew”? Kind regards, Will Sheldon On Sunday, March 23, 2014 at 1:21 AM, John Obaterspok wrote: Hello, A couple of times each day the win 7 machine is not able to lookup hosts on the ipa domain. A ipconfig /renew always allows ipa hosts to be resolvable again. Any ideas why this happens? -- john ___ Freeipa-users mailing list Freeipa-users@redhat.com (mailto:Freeipa-users@redhat.com) https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] About Windows client
I’d be curious to see how well a solution that combines pGina using RADIUS against some middleware like the Gluu server (www.gluu.org) backed by IPA would work. It strikes me that getting domain federation between IPA and Gluu would tick a lot of boxes as it seems to offer a host of authentication and accounting interfaces including oAuth, SAML, OpenID and of course RADIUS. Kind regards, Will Sheldon +1.778-689-1244 On Saturday, March 22, 2014 at 2:17 PM, Dmitri Pal wrote: On 03/22/2014 01:18 PM, Arthur wrote: Dmitri Pal wrote: On 03/20/2014 11:15 PM, Arthur Faizullin wrote: HI! I've got some thoughts on 4-th point: there is a http://pgina.org/ pgina project, may be them are able to do such thing. Yes pgina is one of the options. Someone would have to take it and integrate with MIT Kerberos for Windows if it is not already doing so. But I suspect that it would be more a project in itself that would leverage code from MIT and may be pgina to integrate different parts. The biggest part figuring out the domain affiliation. I mean the use cases like this: a) The system is domainless but user authentictaes with user name and password against IPA b) The system is domainless but user authentictaes with user name and OTP against IPA c) The system is in an AD domain trusted by IdM domain but user authenticates with user name and password against IPA because he is in IdM domain. d) The system is in an AD domain trusted by IdM domain but user authenticates with user name and password against IPA because he is in IdM domain. More to research. We can help with guidance if someone wants to run with it. Thanks Dmitri 20.02.2014 04:23, Dmitri Pal пишет: Hello, I want to summarize our position regarding joining Windows systems into IPA. 1) If you already have AD we recommend using this system with AD and using trusts between AD and IPA. 2) If you do not have AD then use Samba 4 instead of it. It would be great when Samba 4 grows capability to establish trusts. Right now it can't but there is an effort going on. If you are interested - please contribute. 3) If neither of the two options work for you you can configure Windows system to work directly with IPA as described on the wiki. It is an option of last resort because IPA does not provide the services windows client expects. If this is good enough for you, fine by us. 4) Build a native Windows client (cred provider) for IPA using latest Kerberos. IMO this would be really useful if someone does that because we will not build this ourselves. With the native OTP support in IPA it becomes a real business opportunity to provide a native 2FA inside enterprise across multiple platforms. But please do it open source way otherwise we would not recommend you ;-) ___ Freeipa-users mailing list Freeipa-users@redhat.com (mailto:Freeipa-users@redhat.com) https://www.redhat.com/mailman/listinfo/freeipa-users My friend agreed to try. He is C# programmer. But the problem that has low knowledge about kerberos, GSSAPI, and I could not told him what is wrong with current pgina's ldap plugin. He does not want to subscribe to freeipa mail-lists, so may be I shall give him your (Dmitri) e-mail? He speaks russian :) List is really the way to develop open source software collaboratively. This is what we are doing here. We can agree that the communication about the topic will be prefixed in such a way that he can create a filter so that he would get only mails that match the filter. Would that work? I am not sure that I would be able to provide all the support. We are a community here and we have different roles and angles. Working with just one person would not fly, sorry. ___ Freeipa-users mailing list Freeipa-users@redhat.com (mailto:Freeipa-users@redhat.com) https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ (http://www.redhat.com/carveoutcosts/) ___ Freeipa-users mailing list Freeipa-users@redhat.com (mailto:Freeipa-users@redhat.com) https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] adding ubuntu client to red hat server
I ran into this, there was a post bout it a little while back. It seems that you can modify ipapython/version.py to revert the version number for enrolment, then revert it. with no ill effects. My script looks like: #revert reported version of ipapython so keys will upload properly (backup first tho) cp /usr/share/pyshared/ipapython/version.py /usr/share/pyshared/ipapython/version.py.bak sed -i s/API_VERSION=.*/API_VERSION=u'2.49'/g /usr/share/pyshared/ipapython/version.py # install! ipa-client-install -d -U --enable-dns-updates --hostname=$FQDN --mkhomedir --password=$PASS #revert change to the ipapython version back again #rm -f /usr/share/pyshared/ipapython/version.py mv /usr/share/pyshared/ipapython/version.py.bak /usr/share/pyshared/ipapython/version.py Kind regards, Will Sheldon +1.778-689-1244 On Friday, February 21, 2014 at 9:20 AM, Todd Maugh wrote: Hello, Another day another issue it seems :) so I'm trying to set up an ubunutu client I get almost all the way through the install and it fails with a version error. Ive hear this is a known bug and there is a fix out there. although Im not sure how to apply the fix or get the older client install. my error is as follows: Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' host_mod: 2.58 client incompatible with 2.49 server at u'https://se-idm-01.boingo.com/ipa/xml' Failed to upload host SSH public keys. Please help Thanks -Todd tma...@boingo.com (mailto:tma...@boingo.com) ___ Freeipa-users mailing list Freeipa-users@redhat.com (mailto:Freeipa-users@redhat.com) https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] adding ubuntu client to red hat server
I also ran into this problem. I ended up using vm’s to test and just reverting to snapshots. I believe that the install script checks for presence a couple of files that you can delete to be able retry though, have a look in the install script. (Also, did you try with ‘—force'?) Kind regards, Will Sheldon +1.778-689-1244 On Friday, February 21, 2014 at 9:42 AM, Todd Maugh wrote: thanks IM trying that but running in to an issue where it says im still installed I run the uninstall command and I get this root@se-idm-ubuntu-client-01:~# ipa-client-install --uninstall Unconfigured automount client failed: [Errno 2] No such file or directory certmonger failed to start: [Errno 2] No such file or directory: '/var/run/ipa/services.list' certmonger failed to stop: [Errno 2] No such file or directory: '/var/run/ipa/services.list' Disabling client Kerberos and LDAP configurations Failed to remove krb5/LDAP configuration: isnt there a conf file I can remove or a a way to force the uninstall? From: Will Sheldon [m...@willsheldon.com (mailto:m...@willsheldon.com)] Sent: Friday, February 21, 2014 9:32 AM To: Todd Maugh Cc: freeipa-users@redhat.com (mailto:freeipa-users@redhat.com) Subject: Re: [Freeipa-users] adding ubuntu client to red hat server I ran into this, there was a post bout it a little while back. It seems that you can modify ipapython/version.py to revert the version number for enrolment, then revert it. with no ill effects. My script looks like: #revert reported version of ipapython so keys will upload properly (backup first tho) cp /usr/share/pyshared/ipapython/version.py /usr/share/pyshared/ipapython/version.py.bak sed -i s/API_VERSION=.*/API_VERSION=u'2.49'/g /usr/share/pyshared/ipapython/version.py # install! ipa-client-install -d -U --enable-dns-updates --hostname=$FQDN --mkhomedir --password=$PASS #revert change to the ipapython version back again #rm -f /usr/share/pyshared/ipapython/version.py mv /usr/share/pyshared/ipapython/version.py.bak /usr/share/pyshared/ipapython/version.py Kind regards, Will Sheldon +1.778-689-1244 On Friday, February 21, 2014 at 9:20 AM, Todd Maugh wrote: Hello, Another day another issue it seems :) so I'm trying to set up an ubunutu client I get almost all the way through the install and it fails with a version error. Ive hear this is a known bug and there is a fix out there. although Im not sure how to apply the fix or get the older client install. my error is as follows: Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' host_mod: 2.58 client incompatible with 2.49 server at u'https://se-idm-01.boingo.com/ipa/xml' Failed to upload host SSH public keys. Please help Thanks -Todd tma...@boingo.com (mailto:tma...@boingo.com) ___ Freeipa-users mailing list Freeipa-users@redhat.com (mailto:Freeipa-users@redhat.com) https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] adding ubuntu client to red hat server
Do you have your IPA server set as the name server for the client in /etc/resolv.conf ? This is my install script, it may help you a bit. It does need a bit more work http://pastebin.com/mqdTZ3RU Ideally I’d like to convert it to an ansible playbook and have it from from the IPA host. Slightly unrelated, but have a read of this ticket, it makes some good suggestions at the bottom: https://bugs.launchpad.net/bugs/1280215 Kind regards, Will Sheldon +1.778-689-1244 On Friday, February 21, 2014 at 9:55 AM, Todd Maugh wrote: OK I got it to go through with this but i don't understand the errors cause it didn't seem to work. Domain boingo.com (http://boingo.com) is already configured in existing SSSD config, creating a new one. The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall. Configured /etc/sssd/sssd.conf Configured /etc/krb5.conf for IPA realm BOINGO.COM trying https://se-idm-01.boingo.com/ipa/xml Forwarding 'env' to server u'https://se-idm-01.boingo.com/ipa/xml' Hostname (se-idm-ubuntu-client-01.boingo.com (http://se-idm-ubuntu-client-01.boingo.com)) not found in DNS Failed to update DNS records. certmonger failed to stop: [Errno 2] No such file or directory: '/var/run/ipa/services.list' Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' Could not update DNS SSHFP records. From: Will Sheldon [m...@willsheldon.com (mailto:m...@willsheldon.com)] Sent: Friday, February 21, 2014 9:46 AM To: Todd Maugh Cc: freeipa-users@redhat.com (mailto:freeipa-users@redhat.com) Subject: Re: [Freeipa-users] adding ubuntu client to red hat server I also ran into this problem. I ended up using vm’s to test and just reverting to snapshots. I believe that the install script checks for presence a couple of files that you can delete to be able retry though, have a look in the install script. (Also, did you try with ‘—force'?) Kind regards, Will Sheldon +1.778-689-1244 On Friday, February 21, 2014 at 9:42 AM, Todd Maugh wrote: thanks IM trying that but running in to an issue where it says im still installed I run the uninstall command and I get this root@se-idm-ubuntu-client-01:~# ipa-client-install --uninstall Unconfigured automount client failed: [Errno 2] No such file or directory certmonger failed to start: [Errno 2] No such file or directory: '/var/run/ipa/services.list' certmonger failed to stop: [Errno 2] No such file or directory: '/var/run/ipa/services.list' Disabling client Kerberos and LDAP configurations Failed to remove krb5/LDAP configuration: isnt there a conf file I can remove or a a way to force the uninstall? From: Will Sheldon [m...@willsheldon.com (mailto:m...@willsheldon.com)] Sent: Friday, February 21, 2014 9:32 AM To: Todd Maugh Cc: freeipa-users@redhat.com (mailto:freeipa-users@redhat.com) Subject: Re: [Freeipa-users] adding ubuntu client to red hat server I ran into this, there was a post bout it a little while back. It seems that you can modify ipapython/version.py to revert the version number for enrolment, then revert it. with no ill effects. My script looks like: #revert reported version of ipapython so keys will upload properly (backup first tho) cp /usr/share/pyshared/ipapython/version.py /usr/share/pyshared/ipapython/version.py.bak sed -i s/API_VERSION=.*/API_VERSION=u'2.49'/g /usr/share/pyshared/ipapython/version.py # install! ipa-client-install -d -U --enable-dns-updates --hostname=$FQDN --mkhomedir --password=$PASS #revert change to the ipapython version back again #rm -f /usr/share/pyshared/ipapython/version.py mv /usr/share/pyshared/ipapython/version.py.bak /usr/share/pyshared/ipapython/version.py Kind regards, Will Sheldon +1.778-689-1244 On Friday, February 21, 2014 at 9:20 AM, Todd Maugh wrote: Hello, Another day another issue it seems :) so I'm trying to set up an ubunutu client I get almost all the way through the install and it fails with a version error. Ive hear this is a known bug and there is a fix out there. although Im not sure how to apply the fix or get the older client install. my error is as follows: Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub Forwarding 'host_mod' to server u'https://se-idm-01.boingo.com/ipa/xml' host_mod: 2.58 client incompatible with 2.49 server at u'https://se-idm-01.boingo.com/ipa/xml' Failed to upload host SSH public keys. Please help Thanks -Todd
Re: [Freeipa-users] authentication against compat
Is SSSD working for IPA sudo now? I saw this From Jakub Horozek in this list a little while back: Unfortunately with 6.5 there is still no sudo ipa provider, there might be with one in 6.6. So in order to download the sudo rules you need to configure the LDAP sudo provider manually. Will. On Wednesday, February 12, 2014 at 2:57 PM, Dmitri Pal wrote: On 02/12/2014 05:00 PM, Tamas Papp wrote: On 02/12/2014 07:30 PM, Dmitri Pal wrote: Please check SSSD web site for guidelines and if you have any questions do not hesitate to ask on the sssd-users list. SSSD is the best you can get nowadays for the connection of the client systems to the central identity stores. If you plan to use it with IPA you ho not need to configure sssd manually. ipa-client-install will do the trick. Just install ipa-client package and run the command. It was quite pathetic, when last time I tried on ubuntu. I'll try sssd again, if I have spare time. Thanks, tamas Timo Aaltonen is your man then. ;-) -- Thank you, Dmitri Pal Sr. Engineering Manager for IdM portfolio Red Hat Inc. --- Looking to carve out IT costs? www.redhat.com/carveoutcosts/ (http://www.redhat.com/carveoutcosts/) ___ Freeipa-users mailing list Freeipa-users@redhat.com (mailto:Freeipa-users@redhat.com) https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade form Centos to Fedora (3.0.0 - 3.3.3)
On 2/5/2014, 1:35 AM, Rob Crittenden wrote: Will Sheldon wrote: Hello IPA users :) We have implemented IPA using the packaged version in centos 6.5 (which is 3.0.0-37.el6), but have been playing with the more recent version in Fedora 19 (3.3.3-2.fc19) and are quite keen to take advantage of the shiny new features, so are thinking about migrating. Has anyone done this? Is there an easy way to migrate/upgrade? What would happen if I tried to setup a FC19 replica, would it get angry and break? We only have users in production so far, (no production clients or issued certs) so maybe the user migration script mentioned in previous posts would be the best bet? Any pointers would be hugely appreciated.. This is exactly the way to migrate between versions. You'll want to set up a CA on the F19 server for sure, and DNS if you're using that. The idea is that you set up the new master, spend some time (days, weeks not months) verifying that things are working ok, then remove the old server and things should continue to just work. We also recommend having at least two masters with CAs for redundancy and avoiding a single point of failure. We have discovered a bug in the way clients are enrolled though. We store the name of the master you enroll against. Normally this isn't a big deal, especially if you use SRV records. The problem is if that some tools use the master from this file to connect to and not SRV records, so you may want to run around to your clients and change this in /etc/ipa/default.conf once the migration is complete. rob Yay! That’s easier than I thought it would be, thanks Rob. Would this work as a solution? 1) Leave current centos server (ipa.domain.com (http://ipa.domain.com)) in production 2) Configure new FC19 ipa server as a replica (newipa.domain.com (http://newipa.domain.com)) using the server install script 3) Check that newipa.domain.com (http://newipa.domain.com) is functioning as expected. 4) Remove centos server from production (not checked, but I assume there is a documented process for this) 5) Install new FC19 replica using same IP and DNS name as the old centos server (ipa.domain.com). ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Upgrade form Centos to Fedora (3.0.0 - 3.3.3)
Hello IPA users :) We have implemented IPA using the packaged version in centos 6.5 (which is 3.0.0-37.el6), but have been playing with the more recent version in Fedora 19 (3.3.3-2.fc19) and are quite keen to take advantage of the shiny new features, so are thinking about migrating. Has anyone done this? Is there an easy way to migrate/upgrade? What would happen if I tried to setup a FC19 replica, would it get angry and break? We only have users in production so far, (no production clients or issued certs) so maybe the user migration script mentioned in previous posts would be the best bet? Any pointers would be hugely appreciated.. -- Kind regards, Will Sheldon ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating
I’m not too concerned on the default as long as the user is warned (or even maybe asked) at install time. Kind regards, Will Sheldon +1.778-689-1244 On Monday, January 6, 2014 at 1:57 PM, Sigbjorn Lie wrote: On 03/01/14 20:33, Stephen Ingram wrote: On Fri, Jan 3, 2014 at 10:29 AM, Dmitri Pal d...@redhat.com (mailto:d...@redhat.com) wrote: On 01/03/2014 12:50 PM, Will Sheldon wrote: Thanks Petr, that certainly makes sense from the point of view of functionality. I do think the default is sane, but there are a lot of possible deployment scenarios and my concern is that a junior or time poor admin looking to implement a trusted, secure solution should be made aware of any potential data leakage during configuration, (preferably in big red letters in the documentation, or better still, the install script). Though I am reluctant to draw comparisons between IPA and MS AD they do seem inevitable. AD restricts anonymous binds to the rootDSE entry by default and as such this may be considered by many to be the expected default. Extra care should therefore be made to point out this difference. To do otherwise risks undermining the confidence of users in the security of the solution. It is a double edge sword. We compared IPA to LDAP based solutions and with those you have (had) anonymous bind enabled by default. IMO it is the question of a migration. The field of centralized authentication is crowded with all sorts of different solutions, though not that integrated as AD or IdM. It seems that migrating and then tightening security to the level you need is the way to go. The default you suggest might be a barrier to migration as people usually tackle problems one step at a time. I am not against changing the default eventually but I am not sure it is the time to. But may be I am wrong. Are there any opinions on the matter? I think traditionally LDAP-based solutions have been used as true directories where one might be able to search for people through say a Web-based interface, for example at a university. Whereas AD can also be deployed as a directory, but more often than not though say an email Interface (e.g. Outlook) where the user has already gained access via their own credentials so there was not a need to allow anonymous binds. I like following the tradition of LDAP-based directories where anonymous access is allowed by default, however, it would be really nice as the OP requested to have controls available via the WebUI where the admin could apply ACLs to the directory to restrict access to various areas. As changing the overall access scheme requires a directory restart, I'm not too sure how easy it would be to incorporate that into the WebUI, but maybe a notice somewhere to re-enforce the open nature of the directory if the default is retained. Not to start a flame war here - but I would like to say I disagree with you. :) The traditional LDAP-based solutions you're mentioning keep information that would be open to the public, such as a phone directory. However IPA (like AD) keep sensitive information that should not be open to the public. From a security standpoint it's much easier to forget to secure a piece of information in an open directory, than to simply close the directory off and only open for known entities. In my point of view, it's better to keep these directories closed by default, to anything but authenticated requests. It's a great thing that IPA can easily be configured to either be open or closed to anonymous requests by default. :) Regards, Siggi ___ Freeipa-users mailing list Freeipa-users@redhat.com (mailto:Freeipa-users@redhat.com) https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating
Thanks Petr, that certainly makes sense from the point of view of functionality. I do think the default is sane, but there are a lot of possible deployment scenarios and my concern is that a junior or time poor admin looking to implement a trusted, secure solution should be made aware of any potential data leakage during configuration, (preferably in big red letters in the documentation, or better still, the install script). Though I am reluctant to draw comparisons between IPA and MS AD they do seem inevitable. AD restricts anonymous binds to the rootDSE entry by default and as such this may be considered by many to be the expected default. Extra care should therefore be made to point out this difference. To do otherwise risks undermining the confidence of users in the security of the solution. On Fri, Jan 3, 2014 at 4:53 AM, Petr Viktorin pvikt...@redhat.com wrote: On 01/03/2014 02:23 AM, Will Sheldon wrote: This is cause for concern. Is there a hardening / best practices for production guide anywhere, did I miss a section of the documentation? What else do I need to secure? I understand that there is a tradeoff between security and compatibility, but maybe there should be a ipa-secure script somewhere? We are working on making the read permissions granular, so you can make your own tradeoffs if IPA defaults aren't appropriate for your use. The work is tracked in https://fedorahosted.org/freeipa/ticket/3566 and linked tickets 4032-4034. On Wed, Jan 1, 2014 at 10:41 AM, Jitse Klomp jitsekl...@gmail.com mailto:jitsekl...@gmail.com wrote: It is possible to disable anonymous binds to the directory server. Take a look at https://docs.fedoraproject.__org/en-US/Fedora/18/html/__ FreeIPA_Guide/disabling-anon-__binds.html https://docs.fedoraproject.org/en-US/Fedora/18/html/ FreeIPA_Guide/disabling-anon-binds.html - Jitse On 01/01/2014 07:01 PM, Rajnesh Kumar Siwal wrote: It exposes the details of all the users/admins in the environment. There should be a user that the IPA should use to fetch the details from the IPA Servers. Without Authentication , no one should be able to fetch any information from the IPA Server. -- Petr³ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Kind regards, Will Sheldon +1.(778)-689-4144 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] ipa-client-install 2.58 client incompatible with 2.49 server
Thanks guys. For now I've just reverted the reported version while the install script runs. It seems to work OK. On Thu, Jan 2, 2014 at 9:06 AM, Martin Kosek mko...@redhat.com wrote: On 12/28/2013 06:50 PM, Rob Crittenden wrote: Will Sheldon wrote: Hello :) I'm trying to setup a ubuntu 12.04.3 client running freeipa-client 3.2.0-0ubuntu1~precise1 form the apt repo at http://ppa.launchpad.net/freeipa/ppa/ubuntu The server is a (fully updated) centos 6.5 box running ipa-server.x86_64 3.0.0-37.el6 The script mostly works on a stock install, but there is an error uploading SSH keys, This appears to be called from the ipa-client-install script line 1436: result = api.Command['host_mod'](unicode(hostname), Which generates the following output when run: stderr= Caught fault 901 from server https://ipa.[domain].com/ipa/xml: 2.58 client incompatible with 2.49 server at u'https://ipa. [domain].com/ipa/xml' host_mod: 2.58 client incompatible with 2.49 server at u'https://ipa.[domain].com/ipa/xml' Failed to upload host SSH public keys. I understand that this is not a critical failure and that I can manually upload the host keys if needed but the bit I don't understand is where the version numbers come from. The API version is baked into the client and server. We generally provide a backwards compatible server, but right now not the client (so a new client can't always have 100% success talking to an old server). We are actually working on this, especially for client enrollment, to make things work more smoothly. How do I revert the api to version 2.49 to match the server? You'd have to modify ipapython/version.py on each client before enrollment. For enrollment I can't think of any side-effects, but if you ever tried the IPA admin tool on such a client then some odd things could happen. What is best practice here, should I be using a different source for the client install script? I don't know what is available for Debian/Ubuntu clients these days. It is being worked on very hard though I think the focus is on the latest source which explains the mismatch. Is there a copy of the correct client files stashed on the server somewhere? Would anyone be interested in helping with development of a yum and apt repo on the server to make all this easier? The server being the IPA server, so it can distribute the client bits? An interesting idea. rob Note that this issue was fixed in FreeIPA version 3.3.2 (upstream ticket https://fedorahosted.org/freeipa/ticket/3931). Thus, when using FreeIPA client 3.3.2 and later, ipa-client-install will upload the SSH keys even to the older SSH server. No other changes required. HTH, Martin -- Kind regards, Will Sheldon +1.(778)-689-4144 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] FreeIPA Security issue : Anonymous user can fetch user details from IPA without authenticating
This is cause for concern. Is there a hardening / best practices for production guide anywhere, did I miss a section of the documentation? What else do I need to secure? I understand that there is a tradeoff between security and compatibility, but maybe there should be a ipa-secure script somewhere? On Wed, Jan 1, 2014 at 10:41 AM, Jitse Klomp jitsekl...@gmail.com wrote: It is possible to disable anonymous binds to the directory server. Take a look at https://docs.fedoraproject.org/en-US/Fedora/18/html/ FreeIPA_Guide/disabling-anon-binds.html - Jitse On 01/01/2014 07:01 PM, Rajnesh Kumar Siwal wrote: It exposes the details of all the users/admins in the environment. There should be a user that the IPA should use to fetch the details from the IPA Servers. Without Authentication , no one should be able to fetch any information from the IPA Server. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Kind regards, Will Sheldon +1.(778)-689-4144 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] ipa-client-install 2.58 client incompatible with 2.49 server
Hello :) I'm trying to setup a ubuntu 12.04.3 client running freeipa-client 3.2.0-0ubuntu1~precise1 form the apt repo at http://ppa.launchpad.net/freeipa/ppa/ubuntu The server is a (fully updated) centos 6.5 box running ipa-server.x86_64 3.0.0-37.el6 The script mostly works on a stock install, but there is an error uploading SSH keys, This appears to be called from the ipa-client-install script line 1436: result = api.Command['host_mod'](unicode(hostname), Which generates the following output when run: stderr= Caught fault 901 from server https://ipa.[domain].com/ipa/xml: 2.58 client incompatible with 2.49 server at u'https://ipa.[domain].com/ipa/xml' host_mod: 2.58 client incompatible with 2.49 server at u'https://ipa. [domain].com/ipa/xml' Failed to upload host SSH public keys. I understand that this is not a critical failure and that I can manually upload the host keys if needed but the bit I don't understand is where the version numbers come from. How do I revert the api to version 2.49 to match the server? What is best practice here, should I be using a different source for the client install script? Is there a copy of the correct client files stashed on the server somewhere? Would anyone be interested in helping with development of a yum and apt repo on the server to make all this easier? -- Kind regards, Will Sheldon ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
