Re: [Freeipa-users] FreeIP just stopped starting
On 08/19/2014 11:08 PM, Chris Whittle wrote: Here is what I get if I try to start it manually... Any ideas? [root@itservices /]# /usr/sbin/ipactl start Starting Directory Service Starting dirsrv: COLLECTIVEBIAS-COM... [ OK ] PKI-IPA... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached:[ OK ] Starting HTTP Service Starting httpd:[ OK ] Starting CA Service Starting pki-ca: [ OK ] Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Failed to start CA Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping ipa_memcached:[ OK ] Stopping httpd:[ OK ] Stopping pki-ca: [FAILED] Shutting down dirsrv: COLLECTIVEBIAS-COM... [ OK ] PKI-IPA... [ OK ] Aborting ipactl This error is new to me. PKI service start script apparently calls grep function with wrong arguments. CCing Ade and Endi from PKI team to help. What version of PKIIPA are we talking about? 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
Re: [Freeipa-users] IPA Master Issue - Not starting
Hi Petr, Thanks for your help the other day. Something is bringing down my master instance. i am seeing mismatch on master [root@master init.d]# kvno DNS/master.domain@domain.com DNS/master.domain@domain.com: kvno = 8 [root@master init.d]# klist -kt /etc/named.keytab Keytab name: FILE:/etc/named.keytab KVNO Timestamp Principal - 33 08/20/14 16:41:42 DNS/master.domain@domain.com 33 08/20/14 16:41:42 DNS/master.domain@domain.com 33 08/20/14 16:41:42 DNS/master.domain@domain.com 33 08/20/14 16:41:42 DNS/master.domain@domain.com 34 08/20/14 16:53:29 DNS/master.domain@domain.com 34 08/20/14 16:53:29 DNS/master.domain@domain.com 34 08/20/14 16:53:29 DNS/master.domain@domain.com 34 08/20/14 16:53:29 DNS/master.domain@domain.com 35 08/20/14 16:59:37 DNS/master.domain@domain.com 35 08/20/14 16:59:37 DNS/master.domain@domain.com 35 08/20/14 16:59:37 DNS/master.domain@domain.com 35 08/20/14 16:59:37 DNS/master.domain@domain.com 38 08/20/14 17:02:30 DNS/master.domain@domain.com 38 08/20/14 17:02:30 DNS/master.domain@domain.com 38 08/20/14 17:02:30 DNS/master.domain@domain.com 38 08/20/14 17:02:30 DNS/master.domain@domain.com 41 08/20/14 17:07:45 DNS/master.domain@domain.com 41 08/20/14 17:07:45 DNS/master.domain@domain.com 41 08/20/14 17:07:45 DNS/master.domain@domain.com 41 08/20/14 17:07:45 DNS/master.domain@domain.com 42 08/20/14 17:13:17 DNS/master.domain@domain.com 42 08/20/14 17:13:17 DNS/master.domain@domain.com 42 08/20/14 17:13:17 DNS/master.domain@domain.com 42 08/20/14 17:13:17 DNS/master.domain@domain.com 45 08/20/14 17:20:34 DNS/master.domain@domain.com 45 08/20/14 17:20:34 DNS/master.domain@domain.com 45 08/20/14 17:20:34 DNS/master.domain@domain.com 45 08/20/14 17:20:34 DNS/master.domain@domain.com 46 08/20/14 17:35:00 DNS/master.domain@domain.com 46 08/20/14 17:35:00 DNS/master.domain@domain.com 46 08/20/14 17:35:00 DNS/master.domain@domain.com 46 08/20/14 17:35:00 DNS/master.domain@domain.com 47 08/20/14 17:37:43 DNS/master.domain@domain.com 47 08/20/14 17:37:43 DNS/master.domain@domain.com 47 08/20/14 17:37:43 DNS/master.domain@domain.com 47 08/20/14 17:37:43 DNS/master.domain@domain.com 48 08/20/14 17:41:42 DNS/master.domain@domain.com 48 08/20/14 17:41:42 DNS/master.domain@domain.com 48 08/20/14 17:41:42 DNS/master.domain@domain.com 48 08/20/14 17:41:42 DNS/master.domain@domain.com 49 08/20/14 17:43:43 DNS/master.domain@domain.com 49 08/20/14 17:43:44 DNS/master.domain@domain.com 49 08/20/14 17:43:44 DNS/master.domain@domain.com 49 08/20/14 17:43:44 DNS/master.domain@domain.com [root@master init.d]# also here is output from /var/log/messages whilst trying to ipactl start [root@master init.d]# sudo ipactl start Starting Directory Service Starting dirsrv: domain-COM... [ OK ] PKI-IPA... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting DNS Service Starting named: 2014-08-20T18:00:22.098747+10:00 master named[20827]: starting BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 -u named 2014-08-20T18:00:22.099552+10:00 master named[20827]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE' 2014-08-20T18:00:22.099633+10:00 master named[20827]: 2014-08-20T18:00:22.099688+10:00 master named[20827]: BIND 9 is maintained by Internet Systems Consortium, 2014-08-20T18:00:22.099750+10:00 master named[20827]: Inc. (ISC), a non-profit 501(c)(3) public-benefit
Re: [Freeipa-users] IPA Master Issue - Not starting
On 20.8.2014 10:02, Peter Grant wrote: Hi Petr, Thanks for your help the other day. Something is bringing down my master instance. i am seeing mismatch on master [root@master init.d]# kvno DNS/master.domain@domain.com DNS/master.domain@domain.com: kvno = 8 [root@master init.d]# klist -kt /etc/named.keytab Keytab name: FILE:/etc/named.keytab KVNO Timestamp Principal - 33 08/20/14 16:41:42 DNS/master.domain@domain.com 33 08/20/14 16:41:42 DNS/master.domain@domain.com 33 08/20/14 16:41:42 DNS/master.domain@domain.com 33 08/20/14 16:41:42 DNS/master.domain@domain.com 34 08/20/14 16:53:29 DNS/master.domain@domain.com 34 08/20/14 16:53:29 DNS/master.domain@domain.com 34 08/20/14 16:53:29 DNS/master.domain@domain.com 34 08/20/14 16:53:29 DNS/master.domain@domain.com 35 08/20/14 16:59:37 DNS/master.domain@domain.com 35 08/20/14 16:59:37 DNS/master.domain@domain.com 35 08/20/14 16:59:37 DNS/master.domain@domain.com 35 08/20/14 16:59:37 DNS/master.domain@domain.com 38 08/20/14 17:02:30 DNS/master.domain@domain.com 38 08/20/14 17:02:30 DNS/master.domain@domain.com 38 08/20/14 17:02:30 DNS/master.domain@domain.com 38 08/20/14 17:02:30 DNS/master.domain@domain.com 41 08/20/14 17:07:45 DNS/master.domain@domain.com 41 08/20/14 17:07:45 DNS/master.domain@domain.com 41 08/20/14 17:07:45 DNS/master.domain@domain.com 41 08/20/14 17:07:45 DNS/master.domain@domain.com 42 08/20/14 17:13:17 DNS/master.domain@domain.com 42 08/20/14 17:13:17 DNS/master.domain@domain.com 42 08/20/14 17:13:17 DNS/master.domain@domain.com 42 08/20/14 17:13:17 DNS/master.domain@domain.com 45 08/20/14 17:20:34 DNS/master.domain@domain.com 45 08/20/14 17:20:34 DNS/master.domain@domain.com 45 08/20/14 17:20:34 DNS/master.domain@domain.com 45 08/20/14 17:20:34 DNS/master.domain@domain.com 46 08/20/14 17:35:00 DNS/master.domain@domain.com 46 08/20/14 17:35:00 DNS/master.domain@domain.com 46 08/20/14 17:35:00 DNS/master.domain@domain.com 46 08/20/14 17:35:00 DNS/master.domain@domain.com 47 08/20/14 17:37:43 DNS/master.domain@domain.com 47 08/20/14 17:37:43 DNS/master.domain@domain.com 47 08/20/14 17:37:43 DNS/master.domain@domain.com 47 08/20/14 17:37:43 DNS/master.domain@domain.com 48 08/20/14 17:41:42 DNS/master.domain@domain.com 48 08/20/14 17:41:42 DNS/master.domain@domain.com 48 08/20/14 17:41:42 DNS/master.domain@domain.com 48 08/20/14 17:41:42 DNS/master.domain@domain.com 49 08/20/14 17:43:43 DNS/master.domain@domain.com 49 08/20/14 17:43:44 DNS/master.domain@domain.com 49 08/20/14 17:43:44 DNS/master.domain@domain.com 49 08/20/14 17:43:44 DNS/master.domain@domain.com [root@master init.d]# also here is output from /var/log/messages whilst trying to ipactl start [root@master init.d]# sudo ipactl start Starting Directory Service Starting dirsrv: domain-COM... [ OK ] PKI-IPA... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting DNS Service Starting named: 2014-08-20T18:00:22.098747+10:00 master named[20827]: starting BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 -u named 2014-08-20T18:00:22.099552+10:00 master named[20827]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FO! RTIFY_SOUR CE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE' 2014-08-20T18:00:22.099633+10:00 master named[20827]: 2014-08-20T18:00:22.099688+10:00 master named[20827]: BIND 9 is maintained by Internet Systems Consortium,
Re: [Freeipa-users] Need for some pull-style replication, or an alternate solution
On 08/19/2014 07:55 PM, Joshua J. Kugler wrote: A replica must connect to the master for initial setup; after that, the master pushes to the replica. j On Tuesday, August 19, 2014 09:26:11 Ludwig Krispenz wrote: What's wrong with your scenario B: master(s) in internal network, they can contact consumers in DMZ and remote rack and replicate to them. What do you mean by to contact for setup ? Ludwig On 08/19/2014 03:12 AM, Joshua J. Kugler wrote: So, we have a need for replication, but the existing push-only methodology doesn't work for us. I suppose our problems could be attributed to over- zealous network rules, but it is what it is. :) I'd love to change our network policy, but we aren't in charge of network policy, and there is no way I'm swaying the person that is. Topology: 1) DMZ environments 1,...,n 2) An Internal network 3) A remote rack in a data center. Rules (by talk I mean initiate connections to): 1) DMZs can talk to each other, somewhat. 2) The Internal network can talk to the DMZs 3) The DMZ *cannot* connect to the Internal network 4) The remote rack of course cannot contact the Internal network, but can contact the DMZs. Scenario A, Master in a DMZ: - Slave in the Internal network could contact the DMZ master for replica setup, but the Master could not contact the slave to push updates - Slave in the remote rack could contact master in DMZ, but incoming to remote rack is very restrictive, so it is possible that master couldn't push. Scenario B: Master in the Internal network. - Slaves in DMZ and remote rack couldn't contact master for setup, although the master could contact the slaves to push updates. Scenario C: Master in remote rack - Not acceptable as remote rack is a testing rack, and may go down at any time. So, the best solution, from my current understanding is being able to somehow do pull-updates for replicas, because then we could have this: - Master in DMZs - Slaves in Internal network can contact Master in DMZ for replica setup and updates - Slaves in remote rack can contact Master in DMZ for replica setup and updates Any feedback is appreciated, especially if I'm missing something...obvious or minor. j I think you capture the problem correctly. There is unfortunately no solution for this at the moment. We considered looking into read only replicas but this is not exactly what would help here either since changes to RO replicas would be rerouted to the real masters and thos need to be accessible from DMZ or remote req in your case - so it will be inbound connection here. I am not sure there is a way to help you here with the current software. The only option I see is a two different domains - internal and external with some manually set trust in between. You bight be able to sync people in some way with some scripts but still that would be quite fragile. Are the users operating inside the FW and in DMZ/remote are really same users? -- 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
Re: [Freeipa-users] dirsrv access log redirect
On 08/20/2014 06:23 AM, barry...@gmail.com wrote: Dear all: I got 2 servers as cluster ... how can i redirect all logs server2 's /var/log/dirsrv/slapd-abc.com/access http://slapd-abc.com/access to server 1 's /var/log/dirsrv/slapd-abc.com/access http://slapd-abc.com/access so i can view once ?what config should consider ? Or should i use syslog to collect server2 and redirect all to server 1 ? thks You should use log collection tools of your choice to collect and process the logs. You can send logs to syslog and then use rsyslog to collect it. After that you can use different tools to process it: logstash, splunk, etc. -- 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] i inetgrated ipa server with AD but users AD can not loggin on server linux?
hi Having a particularly weird problem. We have moved from AD(windows 2008 R2) to ipa server(centos 6.5). and i integrated ipa with AD machine linux joined with ipa and machine windowse joined with AD. users AD can loggin in cli mode in system linux (centos 6.5) but can not in GUI mod loggin error message in file /var/log/security -- pam: gdm-password[2685]: pam_unix(gdm-password:auth): authentication failure: logname= uid=0 euid=0 tty=:0 ruser= rhost= rhost= user=sallea@AD pam: gdm-password[2685]: pam_sss(gdm-password:auth): user info message: your password will expire in 40 day pam: gdm-password[2685]:pam_sss( gdm-password:auth): authenticate success: logname= uid=0 euid=0 tty=:0 ruser= rhost= rhost= user=sallea@AD pam: gdm-password[2685]:pam_unix (gdm-password:session): session opened for user sallea@AD by (uid=0) polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session4 (system bus name :1.116 , object path /org/gnome/PolcyKit1/AuthenticationAgent, - Ignored: local en_US) (disconnected from bus) pam: gdm-password[2685]: pam_unix (gdm-password:session): session closed for user sallea@AD -- and context file /etc/pam.d/password-auth --- authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid = 500 quiet authsufficientpam_sss.so use_first_pass authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session require pam_sss.so -- how to solve this problem? thanks -- 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] Need for some pull-style replication, or an alternate solution
On 20.8.2014 10:58, Dmitri Pal wrote: On 08/19/2014 07:55 PM, Joshua J. Kugler wrote: A replica must connect to the master for initial setup; after that, the master pushes to the replica. j On Tuesday, August 19, 2014 09:26:11 Ludwig Krispenz wrote: What's wrong with your scenario B: master(s) in internal network, they can contact consumers in DMZ and remote rack and replicate to them. What do you mean by to contact for setup ? Ludwig On 08/19/2014 03:12 AM, Joshua J. Kugler wrote: So, we have a need for replication, but the existing push-only methodology doesn't work for us. I suppose our problems could be attributed to over- zealous network rules, but it is what it is. :) I'd love to change our network policy, but we aren't in charge of network policy, and there is no way I'm swaying the person that is. Topology: 1) DMZ environments 1,...,n 2) An Internal network 3) A remote rack in a data center. Rules (by talk I mean initiate connections to): 1) DMZs can talk to each other, somewhat. 2) The Internal network can talk to the DMZs 3) The DMZ *cannot* connect to the Internal network 4) The remote rack of course cannot contact the Internal network, but can contact the DMZs. Scenario A, Master in a DMZ: - Slave in the Internal network could contact the DMZ master for replica setup, but the Master could not contact the slave to push updates - Slave in the remote rack could contact master in DMZ, but incoming to remote rack is very restrictive, so it is possible that master couldn't push. Scenario B: Master in the Internal network. - Slaves in DMZ and remote rack couldn't contact master for setup, although the master could contact the slaves to push updates. Scenario C: Master in remote rack - Not acceptable as remote rack is a testing rack, and may go down at any time. So, the best solution, from my current understanding is being able to somehow do pull-updates for replicas, because then we could have this: - Master in DMZs - Slaves in Internal network can contact Master in DMZ for replica setup and updates - Slaves in remote rack can contact Master in DMZ for replica setup and updates Any feedback is appreciated, especially if I'm missing something...obvious or minor. j I think you capture the problem correctly. There is unfortunately no solution for this at the moment. We considered looking into read only replicas but this is not exactly what would help here either since changes to RO replicas would be rerouted to the real masters and thos need to be accessible from DMZ or remote req in your case - so it will be inbound connection here. I am not sure there is a way to help you here with the current software. The only option I see is a two different domains - internal and external with some manually set trust in between. You bight be able to sync people in some way with some scripts but still that would be quite fragile. Are the users operating inside the FW and in DMZ/remote are really same users? Or IPA-to-IPA trust? :-) Joshua, if you want to experiment: Ludwig said earlier in this thread that 389 replication will work fine if master is inside internal network (and thus able to contact other replicas in DMZ or external network). It seems to me that main *technical* problem is replica setup phase where replica contacts the original master and not the other way around. You can use e.g. SSH from master to replica and do some tricks with port forwarding and iptables/routing table so the replica will be able to contact the master inside internal network. (That will breach all policies you have, of course.) If you want to experiment even more, you can try to use port forwarding for replica setup and then close the hole. 389 replication should work because master will connect to replica and not the other way around. I'm not sure what else will break... -- 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
Re: [Freeipa-users] FreeIP just stopped starting
How is the best way to determine the version? On Wed, Aug 20, 2014 at 2:29 AM, Martin Kosek mko...@redhat.com wrote: On 08/19/2014 11:08 PM, Chris Whittle wrote: Here is what I get if I try to start it manually... Any ideas? [root@itservices /]# /usr/sbin/ipactl start Starting Directory Service Starting dirsrv: COLLECTIVEBIAS-COM... [ OK ] PKI-IPA... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached:[ OK ] Starting HTTP Service Starting httpd:[ OK ] Starting CA Service Starting pki-ca: [ OK ] Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Failed to start CA Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping ipa_memcached:[ OK ] Stopping httpd:[ OK ] Stopping pki-ca: [FAILED] Shutting down dirsrv: COLLECTIVEBIAS-COM... [ OK ] PKI-IPA... [ OK ] Aborting ipactl This error is new to me. PKI service start script apparently calls grep function with wrong arguments. CCing Ade and Endi from PKI team to help. What version of PKIIPA are we talking about? 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
Re: [Freeipa-users] i inetgrated ipa server with AD but users AD can not loggin on server linux?
On 08/20/2014 01:45 PM, alireza baghery wrote: hi Having a particularly weird problem. We have moved from AD(windows 2008 R2) to ipa server(centos 6.5). and i integrated ipa with AD machine linux joined with ipa and machine windowse joined with AD. users AD can loggin in cli mode in system linux (centos 6.5) but can not in GUI mod loggin Do I get it right: User from AD walks to a desktop console of the Linux system joined into IPA that is in trust relations with AD and the GDE produces the following log? error message in file /var/log/security -- pam: gdm-password[2685]: pam_unix(gdm-password:auth): authentication failure: logname= uid=0 euid=0 tty=:0 ruser= rhost= rhost= user=sallea@AD pam: gdm-password[2685]: pam_sss(gdm-password:auth): user info message: your password will expire in 40 day pam: gdm-password[2685]:pam_sss( gdm-password:auth): authenticate success: logname= uid=0 euid=0 tty=:0 ruser= rhost= rhost= user=sallea@AD pam: gdm-password[2685]:pam_unix (gdm-password:session): session opened for user sallea@AD by (uid=0) polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session4 (system bus name :1.116 , object path /org/gnome/PolcyKit1/AuthenticationAgent, - Ignored: local en_US) (disconnected from bus) pam: gdm-password[2685]: pam_unix (gdm-password:session): session closed for user sallea@AD -- and context file /etc/pam.d/password-auth --- authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid = 500 quiet authsufficientpam_sss.so use_first_pass authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session require pam_sss.so -- how to solve this problem? thanks -- 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
Re: [Freeipa-users] FreeIP just stopped starting
$ rpm -q freeipa-server if you are running on Fedora. $ rpm -q ipa-server if you are running on RHEL/CentOS. FreeIPA 4.0 later also show version with $ ipa --version or in Web UI. Martin On 08/20/2014 02:54 PM, Chris Whittle wrote: How is the best way to determine the version? On Wed, Aug 20, 2014 at 2:29 AM, Martin Kosek mko...@redhat.com wrote: On 08/19/2014 11:08 PM, Chris Whittle wrote: Here is what I get if I try to start it manually... Any ideas? [root@itservices /]# /usr/sbin/ipactl start Starting Directory Service Starting dirsrv: COLLECTIVEBIAS-COM... [ OK ] PKI-IPA... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached:[ OK ] Starting HTTP Service Starting httpd:[ OK ] Starting CA Service Starting pki-ca: [ OK ] Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Failed to start CA Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping ipa_memcached:[ OK ] Stopping httpd:[ OK ] Stopping pki-ca: [FAILED] Shutting down dirsrv: COLLECTIVEBIAS-COM... [ OK ] PKI-IPA... [ OK ] Aborting ipactl This error is new to me. PKI service start script apparently calls grep function with wrong arguments. CCing Ade and Endi from PKI team to help. What version of PKIIPA are we talking about? 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
Re: [Freeipa-users] FreeIP just stopped starting
ipa-server-3.0.0-37.el6.x86_64 I also found this with no solution https://www.redhat.com/archives/freeipa-users/2013-July/msg00133.html On Wed, Aug 20, 2014 at 8:04 AM, Martin Kosek mko...@redhat.com wrote: $ rpm -q freeipa-server if you are running on Fedora. $ rpm -q ipa-server if you are running on RHEL/CentOS. FreeIPA 4.0 later also show version with $ ipa --version or in Web UI. Martin On 08/20/2014 02:54 PM, Chris Whittle wrote: How is the best way to determine the version? On Wed, Aug 20, 2014 at 2:29 AM, Martin Kosek mko...@redhat.com wrote: On 08/19/2014 11:08 PM, Chris Whittle wrote: Here is what I get if I try to start it manually... Any ideas? [root@itservices /]# /usr/sbin/ipactl start Starting Directory Service Starting dirsrv: COLLECTIVEBIAS-COM... [ OK ] PKI-IPA... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached:[ OK ] Starting HTTP Service Starting httpd:[ OK ] Starting CA Service Starting pki-ca: [ OK ] Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Usage: grep [OPTION]... PATTERN [FILE]... Try `grep --help' for more information. Failed to start CA Service Shutting down Stopping Kerberos 5 KDC: [ OK ] Stopping Kerberos 5 Admin Server: [ OK ] Stopping ipa_memcached:[ OK ] Stopping httpd:[ OK ] Stopping pki-ca: [FAILED] Shutting down dirsrv: COLLECTIVEBIAS-COM... [ OK ] PKI-IPA... [ OK ] Aborting ipactl This error is new to me. PKI service start script apparently calls grep function with wrong arguments. CCing Ade and Endi from PKI team to help. What version of PKIIPA are we talking about? Martin -- Manage your subscription for the
Re: [Freeipa-users] dirsrv access log redirect
Dmitri Pal wrote: On 08/20/2014 06:23 AM, barry...@gmail.com wrote: Dear all: I got 2 servers as cluster ... how can i redirect all logs server2 's /var/log/dirsrv/slapd-abc.com/access http://slapd-abc.com/access to server 1 's /var/log/dirsrv/slapd-abc.com/access http://slapd-abc.com/access so i can view once ?what config should consider ? Or should i use syslog to collect server2 and redirect all to server 1 ? thks You should use log collection tools of your choice to collect and process the logs. You can send logs to syslog and then use rsyslog to collect it. After that you can use different tools to process it: logstash, splunk, etc. Take a look at this page for instructions on redirecting logging in 389-ds: http://www.port389.org/wiki/Named_Pipe_Log_Script rob -- 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] Need for some pull-style replication, or an alternate solution
On 08/20/2014 02:55 PM, Petr Spacek wrote: On 20.8.2014 10:58, Dmitri Pal wrote: On 08/19/2014 07:55 PM, Joshua J. Kugler wrote: A replica must connect to the master for initial setup; after that, the master pushes to the replica. j On Tuesday, August 19, 2014 09:26:11 Ludwig Krispenz wrote: What's wrong with your scenario B: master(s) in internal network, they can contact consumers in DMZ and remote rack and replicate to them. What do you mean by to contact for setup ? Ludwig On 08/19/2014 03:12 AM, Joshua J. Kugler wrote: So, we have a need for replication, but the existing push-only methodology doesn't work for us. I suppose our problems could be attributed to over- zealous network rules, but it is what it is. :) I'd love to change our network policy, but we aren't in charge of network policy, and there is no way I'm swaying the person that is. Topology: 1) DMZ environments 1,...,n 2) An Internal network 3) A remote rack in a data center. Rules (by talk I mean initiate connections to): 1) DMZs can talk to each other, somewhat. 2) The Internal network can talk to the DMZs 3) The DMZ *cannot* connect to the Internal network 4) The remote rack of course cannot contact the Internal network, but can contact the DMZs. Scenario A, Master in a DMZ: - Slave in the Internal network could contact the DMZ master for replica setup, but the Master could not contact the slave to push updates - Slave in the remote rack could contact master in DMZ, but incoming to remote rack is very restrictive, so it is possible that master couldn't push. Scenario B: Master in the Internal network. - Slaves in DMZ and remote rack couldn't contact master for setup, although the master could contact the slaves to push updates. Scenario C: Master in remote rack - Not acceptable as remote rack is a testing rack, and may go down at any time. So, the best solution, from my current understanding is being able to somehow do pull-updates for replicas, because then we could have this: - Master in DMZs - Slaves in Internal network can contact Master in DMZ for replica setup and updates - Slaves in remote rack can contact Master in DMZ for replica setup and updates Any feedback is appreciated, especially if I'm missing something...obvious or minor. j I think you capture the problem correctly. There is unfortunately no solution for this at the moment. We considered looking into read only replicas but this is not exactly what would help here either since changes to RO replicas would be rerouted to the real masters and thos need to be accessible from DMZ or remote req in your case - so it will be inbound connection here. I am not sure there is a way to help you here with the current software. The only option I see is a two different domains - internal and external with some manually set trust in between. You bight be able to sync people in some way with some scripts but still that would be quite fragile. Are the users operating inside the FW and in DMZ/remote are really same users? Or IPA-to-IPA trust? :-) Joshua, if you want to experiment: Ludwig said earlier in this thread that 389 replication will work fine if master is inside internal network (and thus able to contact other replicas in DMZ or external network). It seems to me that main *technical* problem is replica setup phase where replica contacts the original master and not the other way around. yes, and you make it a read only consumer, otherwise it would try to establish a replication connection. So it ends all up in setting this up 'manually'. You can use e.g. SSH from master to replica and do some tricks with port forwarding and iptables/routing table so the replica will be able to contact the master inside internal network. (That will breach all policies you have, of course.) If you want to experiment even more, you can try to use port forwarding for replica setup and then close the hole. 389 replication should work because master will connect to replica and not the other way around. I'm not sure what else will break... -- 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 Master Issue - Not starting
Petr Spacek wrote: On 20.8.2014 10:02, Peter Grant wrote: Hi Petr, Thanks for your help the other day. Something is bringing down my master instance. i am seeing mismatch on master [root@master init.d]# kvno DNS/master.domain@domain.com DNS/master.domain@domain.com: kvno = 8 [root@master init.d]# klist -kt /etc/named.keytab Keytab name: FILE:/etc/named.keytab KVNO Timestamp Principal - 33 08/20/14 16:41:42 DNS/master.domain@domain.com 33 08/20/14 16:41:42 DNS/master.domain@domain.com 33 08/20/14 16:41:42 DNS/master.domain@domain.com 33 08/20/14 16:41:42 DNS/master.domain@domain.com 34 08/20/14 16:53:29 DNS/master.domain@domain.com 34 08/20/14 16:53:29 DNS/master.domain@domain.com 34 08/20/14 16:53:29 DNS/master.domain@domain.com 34 08/20/14 16:53:29 DNS/master.domain@domain.com 35 08/20/14 16:59:37 DNS/master.domain@domain.com 35 08/20/14 16:59:37 DNS/master.domain@domain.com 35 08/20/14 16:59:37 DNS/master.domain@domain.com 35 08/20/14 16:59:37 DNS/master.domain@domain.com 38 08/20/14 17:02:30 DNS/master.domain@domain.com 38 08/20/14 17:02:30 DNS/master.domain@domain.com 38 08/20/14 17:02:30 DNS/master.domain@domain.com 38 08/20/14 17:02:30 DNS/master.domain@domain.com 41 08/20/14 17:07:45 DNS/master.domain@domain.com 41 08/20/14 17:07:45 DNS/master.domain@domain.com 41 08/20/14 17:07:45 DNS/master.domain@domain.com 41 08/20/14 17:07:45 DNS/master.domain@domain.com 42 08/20/14 17:13:17 DNS/master.domain@domain.com 42 08/20/14 17:13:17 DNS/master.domain@domain.com 42 08/20/14 17:13:17 DNS/master.domain@domain.com 42 08/20/14 17:13:17 DNS/master.domain@domain.com 45 08/20/14 17:20:34 DNS/master.domain@domain.com 45 08/20/14 17:20:34 DNS/master.domain@domain.com 45 08/20/14 17:20:34 DNS/master.domain@domain.com 45 08/20/14 17:20:34 DNS/master.domain@domain.com 46 08/20/14 17:35:00 DNS/master.domain@domain.com 46 08/20/14 17:35:00 DNS/master.domain@domain.com 46 08/20/14 17:35:00 DNS/master.domain@domain.com 46 08/20/14 17:35:00 DNS/master.domain@domain.com 47 08/20/14 17:37:43 DNS/master.domain@domain.com 47 08/20/14 17:37:43 DNS/master.domain@domain.com 47 08/20/14 17:37:43 DNS/master.domain@domain.com 47 08/20/14 17:37:43 DNS/master.domain@domain.com 48 08/20/14 17:41:42 DNS/master.domain@domain.com 48 08/20/14 17:41:42 DNS/master.domain@domain.com 48 08/20/14 17:41:42 DNS/master.domain@domain.com 48 08/20/14 17:41:42 DNS/master.domain@domain.com 49 08/20/14 17:43:43 DNS/master.domain@domain.com 49 08/20/14 17:43:44 DNS/master.domain@domain.com 49 08/20/14 17:43:44 DNS/master.domain@domain.com 49 08/20/14 17:43:44 DNS/master.domain@domain.com [root@master init.d]# also here is output from /var/log/messages whilst trying to ipactl start [root@master init.d]# sudo ipactl start Starting Directory Service Starting dirsrv: domain-COM... [ OK ] PKI-IPA... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting DNS Service Starting named: 2014-08-20T18:00:22.098747+10:00 master named[20827]: starting BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 -u named 2014-08-20T18:00:22.099552+10:00 master named[20827]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--target=x86_64-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--with-pic' '--disable-static' '--disable-openssl-version-check' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--enable-fixed-rrset' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'target_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FO! RTIFY_SOUR CE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic' 'CPPFLAGS= -DDIG_SIGCHASE' 2014-08-20T18:00:22.099633+10:00 master named[20827]: 2014-08-20T18:00:22.099688+10:00 master
Re: [Freeipa-users] Improving FreeIPA.org
Original Message Subject: Re: [Freeipa-users] Improving FreeIPA.org Date: Tue, 19 Aug 2014 16:33:49 + From: Choudhury, Suhail suhail.choudh...@bskyb.com To: freeipa-users@redhat.com freeipa-users@redhat.com Hi, I think a small screenshot in the middle or on the side of the main webpage will serve to increase the coolness of the website and may possibly even result in many more people trying it out and visiting the demo. I agree, I think images would help break up some of the content on the homepage. Also I would consider how much content appears on the homepage. In the current state there is so much information which makes it is hard to parse. The information is very dense as well. It might be useful to think about presenting the information on the homepage in the same way you would tell someone verbally about FreeIPA. I think the Bootstrap project does a nice job of presenting an overview of information at a high level - http://getbootstrap.com/ Regards, Suhail Choudhury. DevOps | Recommendations Team | BSkyB Regards, Suhail Choudhury. DevOps | Recommendations Team | BSkyB From: freeipa-users-boun...@redhat.com [freeipa-users-boun...@redhat.com] on behalf of Petr Spacek [pspa...@redhat.com] Sent: 19 August 2014 16:13 To: freeipa-users@redhat.com Subject: [Freeipa-users] Improving FreeIPA.org Hello community, Do you have an idea how to improve Freeipa.org web site? Share it! I will start: The main page currently contains three links placed right above Main features section header: Learn more about FreeIPA • What FreeIPA means for me? • Try FreeIPA in a public demo It seems to me that two links Learn more about FreeIPA [http://www.freeipa.org/page/About] and What FreeIPA means for me? [http://www.freeipa.org/page/Leaflet] are somehow too much for the main page. I propose to either merge About and Leaflet or to hide Leaflet from main page. It would be better to replace Leaftlet with Quick Start Guide: Learn more about FreeIPA • Quick Start Guide • Try FreeIPA in a public demo -- 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 2 client connecting to ipa 3 server
Walid wrote: Hello All, What is the recommendation on having ipa2 clients connecting to IPA 3 server, we have some RHEL5.3 clients (I know they are EOL, however end user still wants as it is) that we would like to connect them to IPA 3.x server running RHEL6.5. Should work fine with no problems. Any one running free-ipa on RHEL instead of the Red Hat packages on RHEL5, and RHEL6? Depending on the versions of IPA and RHEL it can be difficult but not impossible. The biggest obstacle is missing or older dependencies, some of which are extremely non-trivial to backport. RHEL 5 still has Python 2.4 which makes the backport that much more difficult. rob -- 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] admin user ssh required for replication?
All, I'm setting up a new replicated master (CentOS7) from a CentOS 6.5 original master. I added the patch (to the freeIPA 3.3 on CentOS 7) from https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=8c98561c209d0ccaa692a335e3e9a10aec23ee0e to handle the 2 replication IDs bug. The replication fails to complete. If I exclude the connection check, it fails. If I leave the connection check in place, it asks for an ssh password for the admin@original master host. There is no admin user on that machine. The admin user is only in freeIPA. Should there be an admin user account exposed? Did I find a config change between 3.0 and 3.3 releases? -- Jim Kinney Senior System Administrator Department of BioMedical Informatics Emory University jimkin...@emory.edu 404.712.0300 bmi.emory.edu -- 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] i inetgrated ipa server with AD but users AD can not loggin on server linux?
yes right. ipa trust relation with AD and subdomain AD. yes gde produce log On Wed, Aug 20, 2014 at 5:27 PM, Dmitri Pal d...@redhat.com wrote: On 08/20/2014 01:45 PM, alireza baghery wrote: hi Having a particularly weird problem. We have moved from AD(windows 2008 R2) to ipa server(centos 6.5). and i integrated ipa with AD machine linux joined with ipa and machine windowse joined with AD. users AD can loggin in cli mode in system linux (centos 6.5) but can not in GUI mod loggin Do I get it right: User from AD walks to a desktop console of the Linux system joined into IPA that is in trust relations with AD and the GDE produces the following log? error message in file /var/log/security -- pam: gdm-password[2685]: pam_unix(gdm-password:auth): authentication failure: logname= uid=0 euid=0 tty=:0 ruser= rhost= rhost= user=sallea@AD pam: gdm-password[2685]: pam_sss(gdm-password:auth): user info message: your password will expire in 40 day pam: gdm-password[2685]:pam_sss( gdm-password:auth): authenticate success: logname= uid=0 euid=0 tty=:0 ruser= rhost= rhost= user=sallea@AD pam: gdm-password[2685]:pam_unix (gdm-password:session): session opened for user sallea@AD by (uid=0) polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session4 (system bus name :1.116 , object path /org/gnome/PolcyKit1/AuthenticationAgent, - Ignored: local en_US) (disconnected from bus) pam: gdm-password[2685]: pam_unix (gdm-password:session): session closed for user sallea@AD -- and context file /etc/pam.d/password-auth --- authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid = 500 quiet authsufficientpam_sss.so use_first_pass authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session require pam_sss.so -- how to solve this problem? thanks -- 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
Re: [Freeipa-users] admin user ssh required for replication?
Jim Kinney wrote: All, I'm setting up a new replicated master (CentOS7) from a CentOS 6.5 original master. I added the patch (to the freeIPA 3.3 on CentOS 7) from https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=8c98561c209d0ccaa692a335e3e9a10aec23ee0e to handle the 2 replication IDs bug. The replication fails to complete. If I exclude the connection check, it fails. If I leave the connection check in place, it asks for an ssh password for the admin@original master host. There is no admin user on that machine. The admin user is only in freeIPA. Should there be an admin user account exposed? Did I find a config change between 3.0 and 3.3 releases? The admin user is in freeIPA so therefore the user IS on that original master. The connection check is there to confirm that the required ports are available in both directions. If replication is failing it may be due to that, but without details it's hard to say. rob -- 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] i inetgrated ipa server with AD but users AD can not loggin on server linux?
On 08/20/2014 04:29 PM, alireza baghery wrote: yes right. ipa trust relation with AD and subdomain AD. yes gde produce log It seems that you have some custom polkit policy that fails to load. Did you play with some polkit policies? On Wed, Aug 20, 2014 at 5:27 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 08/20/2014 01:45 PM, alireza baghery wrote: hi Having a particularly weird problem. We have moved from AD(windows 2008 R2) to ipa server(centos 6.5). and i integrated ipa with AD machine linux joined with ipa and machine windowse joined with AD. users AD can loggin in cli mode in system linux (centos 6.5) but can not in GUI mod loggin Do I get it right: User from AD walks to a desktop console of the Linux system joined into IPA that is in trust relations with AD and the GDE produces the following log? error message in file /var/log/security -- pam: gdm-password[2685]: pam_unix(gdm-password:auth): authentication failure: logname= uid=0 euid=0 tty=:0 ruser= rhost= rhost= user=sallea@AD pam: gdm-password[2685]: pam_sss(gdm-password:auth): user info message: your password will expire in 40 day pam: gdm-password[2685]:pam_sss( gdm-password:auth): authenticate success: logname= uid=0 euid=0 tty=:0 ruser= rhost= rhost= user=sallea@AD pam: gdm-password[2685]:pam_unix (gdm-password:session): session opened for user sallea@AD by (uid=0) polkitd(authority=local): Unregistered Authentication Agent for session /org/freedesktop/ConsoleKit/Session4 (system bus name :1.116 , object path /org/gnome/PolcyKit1/AuthenticationAgent, - Ignored: local en_US) (disconnected from bus) pam: gdm-password[2685]: pam_unix (gdm-password:session): session closed for user sallea@AD -- and context file /etc/pam.d/password-auth --- authrequired pam_env.so authsufficientpam_unix.so nullok try_first_pass authrequisite pam_succeed_if.so uid = 500 quiet authsufficientpam_sss.so use_first_pass authrequired pam_deny.so account required pam_unix.so account sufficientpam_localuser.so account sufficientpam_succeed_if.so uid 500 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so passwordrequisite pam_cracklib.so try_first_pass retry=3 type= passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass use_authtok passwordsufficientpam_sss.so use_authtok passwordrequired pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session require pam_sss.so -- how to solve this problem? thanks -- 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] ipa-client-install via Kickstart in RHEL7
Hi, We are attempting to run ipa-client-install in the %post section of a Kickstart in order to join the host to an IPA domain (3.3/RHEL7 IdM). We are using something like: /usr/sbin/ipa-client-install -w 'one-time-password' --realm=REALM.COM -U --no-ssh --no-sshd --no-ntp --domain=realm.com The machine does indeed join the domain correctly, but the certmonger request fails. Looking at the logs, we can see this: 2014-08-19T15:02:45Z DEBUG Starting external process 2014-08-19T15:02:45Z DEBUG args=/bin/systemctl is-active certmonger.service 2014-08-19T15:02:45Z DEBUG Process finished, return code=0 2014-08-19T15:02:45Z DEBUG stdout= 2014-08-19T15:02:45Z DEBUG stderr=Running in chroot, ignoring request. The error is occurring because the certmonger service fails to start. This is because systemd is not able to manipulate services in a chrooted environment (ala the anaconda installation environment). Prior to systemd, this would work fine as services could start normally via init in a chroot/%post. Additionally, we see the error: Unable to find 'admin' user with 'getent passwd ad...@domain.com' Again, this is because systemd is unable to start sssd in the chrooted installation environment. I'm wondering if anyone else has experienced these issues with systemd unable to start these required services during installation and what you did to work around them. One option would be to move the ipa-client-install out of Kickstart and have Puppet join the host to the domain post-installation (after firstboot), but this isn't really ideal. Any advice or suggestions would be appreciated. Thanks, Josh -- 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-client-install via Kickstart in RHEL7
On 08/20/2014 09:18 AM, Baird, Josh wrote: Hi, We are attempting to run ipa-client-install in the %post section of a Kickstart in order to join the host to an IPA domain (3.3/RHEL7 IdM). We are using something like: /usr/sbin/ipa-client-install -w 'one-time-password' --realm=REALM.COM -U --no-ssh --no-sshd --no-ntp --domain=realm.com The machine does indeed join the domain correctly, but the certmonger request fails. Looking at the logs, we can see this: 2014-08-19T15:02:45Z DEBUG Starting external process 2014-08-19T15:02:45Z DEBUG args=/bin/systemctl is-active certmonger.service 2014-08-19T15:02:45Z DEBUG Process finished, return code=0 2014-08-19T15:02:45Z DEBUG stdout= 2014-08-19T15:02:45Z DEBUG stderr=Running in chroot, ignoring request. The error is occurring because the certmonger service fails to start. This is because systemd is not able to manipulate services in a chrooted environment (ala the anaconda installation environment). Prior to systemd, this would work fine as services could start normally via init in a chroot/%post. Additionally, we see the error: Unable to find 'admin' user with 'getent passwd ad...@domain.com' Again, this is because systemd is unable to start sssd in the chrooted installation environment. I'm wondering if anyone else has experienced these issues with systemd unable to start these required services during installation and what you did to work around them. One option would be to move the ipa-client-install out of Kickstart and have Puppet join the host to the domain post-installation (after firstboot), but this isn't really ideal. Any advice or suggestions would be appreciated. Create a file that is run at boot, presumably after networking and certmonger are started. Thanks, Josh -- 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] admin user ssh required for replication?
Found a solution: The first replica I built did not have the CA replication setup. So I ran the ipa-ca-install with it's original replica file on the first replica. Now that system is able to generate a replica.gpg file for the new centos7 box. The new box replicated just fine and all is well with it. Now I can resync the ldap on the original master and fix it. Of course the weirdness is the web gui shows data for users but the system itself can't use that data. Maybe I should dig into the pam modules. On Wed, 2014-08-20 at 10:10 -0400, Jim Kinney wrote: All, I'm setting up a new replicated master (CentOS7) from a CentOS 6.5 original master. I added the patch (to the freeIPA 3.3 on CentOS 7) from https://git.fedorahosted.org/cgit/freeipa.git/commit/?id=8c98561c209d0ccaa692a335e3e9a10aec23ee0e to handle the 2 replication IDs bug. The replication fails to complete. If I exclude the connection check, it fails. If I leave the connection check in place, it asks for an ssh password for the admin@original master host. There is no admin user on that machine. The admin user is only in freeIPA. Should there be an admin user account exposed? Did I find a config change between 3.0 and 3.3 releases? -- Jim Kinney Senior System Administrator Department of BioMedical Informatics Emory University jimkin...@emory.edu 404.712.0300 bmi.emory.edu plain text document attachment (ATT1) -- 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 -- Jim Kinney Senior System Administrator Department of BioMedical Informatics Emory University jimkin...@emory.edu 404.712.0300 bmi.emory.edu -- 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 establishing a trust with AD
Hi, I'm attempting to establish a trust between FreeIPA 3.3 and AD 2008 R2. My IPA domain consists of two servers (one master and one replica). I have verified that DNS is configured properly as the IPA domain can resolve AD and the AD domain can resolve IPA hosts. On each IPA server, I performed the following: $ yum install ipa-server-trust-ad samba-client $ ipa-adtrust-install On the main IPA server, I executed the following: $ ipa trust-add --admin administrator --password The output of this command suggests that establishing the trust was successful: - Added Active Directory trust for realm test.lan - Realm name: test.lan Domain NetBIOS name: TEST Domain Security Identifier: S-1-5-21-2234298371-4032204425-1996979893 SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified Additionally, I can also see the IPA domain in Active Directory Domains and Trusts on the Windows side. Next, I successfully requested a service ticket for the AD domain: $ kvno cifs/vmxxenttest01.test@test.lan cifs/vmxxenttest01.test@test.lan: kvno = 4 $ klist | grep TEST 08/20/2014 11:03:47 08/20/2014 21:03:47 cifs/vmxxenttest01.test@test.lan 08/20/2014 11:03:47 08/21/2014 11:00:30 krbtgt/test@qa-unix.domain.com Next, I modified /etc/krb5.conf on both IDM servers (master and replica) and added the following to the [realms] section and restarted krb5kdc: auth_to_local = RULE:[1:$1@$0](^.*@TEST.LAN$)s/@TEST.LAN/@TEST.LAN/ auth_to_local = DEFAULT I also modified /etc/sssd/sssd.conf and added pac to services and subdomains_provider = ipa. Next, I tried to validate the trust from the AD side using the Validate button in AD Domains and Trusts. Once I click the 'Vaildate' button, I choose Yes, validate the incoming trust and specify the IPA admin account and password and get notified that the trust cannot be validated due to There are currently no logon servers available to service the logon requests. It suggests that I reset the trust password, and I accept, but again it fails due to no logon servers. I don't really see anything in the krb5kdc.log logs on the IPA servers. Any ideas how to further troubleshoot this? Thanks, Josh -- 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 2 client connecting to ipa 3 server
Thanks Dmitri, so sssd is out of the picture in this case? On 20 August 2014 16:43, Dmitri Pal d...@redhat.com wrote: On 08/20/2014 03:30 PM, Walid wrote: Hello All, What is the recommendation on having ipa2 clients connecting to IPA 3 server, we have some RHEL5.3 clients (I know they are EOL, however end user still wants as it is) that we would like to connect them to IPA 3.x server running RHEL6.5. Any one running free-ipa on RHEL instead of the Red Hat packages on RHEL5, and RHEL6? regards Walid 5.3 clean can be connected to IPA using pam_krb5 or pam_ldap for authentication and nss_ldap for identity. Perfectly reasonable and supported configuration. No need to run unsupported packages on RHEL. -- 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
Re: [Freeipa-users] ipa 2 client connecting to ipa 3 server
Thanks Rob, we have native python2.4, and anaconda python 2.7, so i guess if anything needs python 2.6 or greater it would not be an issue. I am just wondering if there are people using the upstream project in such a legacy system ;-) On 20 August 2014 16:55, Rob Crittenden rcrit...@redhat.com wrote: Walid wrote: Hello All, What is the recommendation on having ipa2 clients connecting to IPA 3 server, we have some RHEL5.3 clients (I know they are EOL, however end user still wants as it is) that we would like to connect them to IPA 3.x server running RHEL6.5. Should work fine with no problems. Any one running free-ipa on RHEL instead of the Red Hat packages on RHEL5, and RHEL6? Depending on the versions of IPA and RHEL it can be difficult but not impossible. The biggest obstacle is missing or older dependencies, some of which are extremely non-trivial to backport. RHEL 5 still has Python 2.4 which makes the backport that much more difficult. rob -- 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 2 client connecting to ipa 3 server
Walid wrote: Thanks Rob, we have native python2.4, and anaconda python 2.7, so i guess if anything needs python 2.6 or greater it would not be an issue. I am just wondering if there are people using the upstream project in such a legacy system ;-) It's not just python, it's all the modules as well. In the end the issue isn't so much ipa-client as all the related dependencies. The ipa-client package just helps configure things, sssd does all the heavy lifting. If you wanted to backport anything I'd start there, and it is likely extremely non-trivial. I know that people still use RHEL-5 and the current 2.2-based client. It, and its related packages, generally works fine you just miss out on some of the newer features, particularly in sssd (like sudo and autofs). rob On 20 August 2014 16:55, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Walid wrote: Hello All, What is the recommendation on having ipa2 clients connecting to IPA 3 server, we have some RHEL5.3 clients (I know they are EOL, however end user still wants as it is) that we would like to connect them to IPA 3.x server running RHEL6.5. Should work fine with no problems. Any one running free-ipa on RHEL instead of the Red Hat packages on RHEL5, and RHEL6? Depending on the versions of IPA and RHEL it can be difficult but not impossible. The biggest obstacle is missing or older dependencies, some of which are extremely non-trivial to backport. RHEL 5 still has Python 2.4 which makes the backport that much more difficult. rob -- 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 2 client connecting to ipa 3 server
On 08/20/2014 09:43 PM, Rob Crittenden wrote: Walid wrote: Thanks Rob, we have native python2.4, and anaconda python 2.7, so i guess if anything needs python 2.6 or greater it would not be an issue. I am just wondering if there are people using the upstream project in such a legacy system ;-) It's not just python, it's all the modules as well. In the end the issue isn't so much ipa-client as all the related dependencies. The ipa-client package just helps configure things, sssd does all the heavy lifting. If you wanted to backport anything I'd start there, and it is likely extremely non-trivial. I know that people still use RHEL-5 and the current 2.2-based client. It, and its related packages, generally works fine you just miss out on some of the newer features, particularly in sssd (like sudo and autofs). You can try to build sssd on 5.3 but I suspect it will require so many dependencies that you system would look more like a 5.10. You can try but this will be an adventurous effort. For old systems like that we recommend using what they had then and not SSSD. Users will be able to authenticate and posix data will be the same as on the more modern systems which should be sufficient for the needs of those old systems anyways. rob On 20 August 2014 16:55, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Walid wrote: Hello All, What is the recommendation on having ipa2 clients connecting to IPA 3 server, we have some RHEL5.3 clients (I know they are EOL, however end user still wants as it is) that we would like to connect them to IPA 3.x server running RHEL6.5. Should work fine with no problems. Any one running free-ipa on RHEL instead of the Red Hat packages on RHEL5, and RHEL6? Depending on the versions of IPA and RHEL it can be difficult but not impossible. The biggest obstacle is missing or older dependencies, some of which are extremely non-trivial to backport. RHEL 5 still has Python 2.4 which makes the backport that much more difficult. rob -- 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
Re: [Freeipa-users] Problems establishing a trust with AD
On Wed, 20 Aug 2014, Baird, Josh wrote: Hi, I'm attempting to establish a trust between FreeIPA 3.3 and AD 2008 R2. My IPA domain consists of two servers (one master and one replica). I have verified that DNS is configured properly as the IPA domain can resolve AD and the AD domain can resolve IPA hosts. On each IPA server, I performed the following: $ yum install ipa-server-trust-ad samba-client $ ipa-adtrust-install On the main IPA server, I executed the following: $ ipa trust-add --admin administrator --password The output of this command suggests that establishing the trust was successful: - Added Active Directory trust for realm test.lan - Realm name: test.lan Domain NetBIOS name: TEST Domain Security Identifier: S-1-5-21-2234298371-4032204425-1996979893 SID blacklist incoming: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 SID blacklist outgoing: S-1-0, S-1-1, S-1-2, S-1-3, S-1-5-1, S-1-5-2, S-1-5-3, S-1-5-4, S-1-5-5, S-1-5-6, S-1-5-7, S-1-5-8, S-1-5-9, S-1-5-10, S-1-5-11, S-1-5-12, S-1-5-13, S-1-5-14, S-1-5-15, S-1-5-16, S-1-5-17, S-1-5-18, S-1-5-19, S-1-5-20 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified Additionally, I can also see the IPA domain in Active Directory Domains and Trusts on the Windows side. Next, I successfully requested a service ticket for the AD domain: $ kvno cifs/vmxxenttest01.test@test.lan cifs/vmxxenttest01.test@test.lan: kvno = 4 $ klist | grep TEST 08/20/2014 11:03:47 08/20/2014 21:03:47 cifs/vmxxenttest01.test@test.lan 08/20/2014 11:03:47 08/21/2014 11:00:30 krbtgt/test@qa-unix.domain.com All is good. At this point, if kvno as IPA user works against AD DC, you don't need to perform validation from AD side. Next, I modified /etc/krb5.conf on both IDM servers (master and replica) and added the following to the [realms] section and restarted krb5kdc: auth_to_local = RULE:[1:$1@$0](^.*@TEST.LAN$)s/@TEST.LAN/@TEST.LAN/ auth_to_local = DEFAULT The AD domain rule is a bit wrong, the last part (replacement) should be low-cased. auth_to_local = RULE:[1:$1@$0](^.*@TEST.LAN$)s/@TEST.LAN/@test.lan/ I also modified /etc/sssd/sssd.conf and added pac to services and subdomains_provider = ipa. Did you restart sssd at this point? Did you try getent passwd administra...@test.lan or id administra...@test.lan ? Next, I tried to validate the trust from the AD side using the Validate button in AD Domains and Trusts. Once I click the 'Vaildate' button, I choose Yes, validate the incoming trust and specify the IPA admin account and password and get notified that the trust cannot be validated due to There are currently no logon servers available to service the logon requests. It suggests that I reset the trust password, and I accept, but again it fails due to no logon servers. I don't really see anything in the krb5kdc.log logs on the IPA servers. Any ideas how to further troubleshoot this? As I said, if kvno succeeds as IPA user against AD services, no additional validation from AD side is needed. Since you did establish trust using AD admin credentials, IPA did issue request to validate trust automatically. You may re-establish trust if you think your actions on AD side broke something in the trust objects in AD. -- / 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] Ldapsearch with a trailing space
On 08/20/2014 05:01 PM, William wrote: Hi, Semi offtopic, how does one search with ldap for an attribute instance with a trailing space. Consider: cn=foo How do you distinguish this from cn=foo in an ldapsearch? I have tried: ldapsearch (cn=foo) ldapsearch (cn='foo ') ldapsearch ((cn=foo*)(!(cn=foo))) ldapsearch (cn=foo\20) Any other ideas? How did you manage to add an attribute value with a trailing space? -- 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] Ldapsearch with a trailing space
How did you manage to add an attribute value with a trailing space? Excellent question: Someone else in my workplace managed to stuff this one up, so that a users objectClass has a trailing space, thus is returning is base64 on search now. -- William will...@firstyear.id.au -- 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] Ldapsearch with a trailing space
On 08/20/2014 05:28 PM, William wrote: How did you manage to add an attribute value with a trailing space? Excellent question: Someone else in my workplace managed to stuff this one up, so that a users objectClass has a trailing space, thus is returning is base64 on search now. Ok. As to how to fix it: ldapsearch -xLLL -D cn=directory manager -W -s base -b the dn with the broken objectclass 'objectclass=*' objectclass junk.ldif then edit junk.ldif to look like this: dn: the dn with the broken objectclass changetype: modify replace: objectclass objectclass: objectclass: Basically, all of the objectclasses from ldapsearch, but fixing the one with the trailing space Then use ldapmodify ldapmodify -x -D cn=directory manager -W -f junk.ldif As to your original question - I'm not sure - I would have thought the correct way to do it would have been to use the ldap escape sequence for space in the ldap search filter. -- 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] Install FreeIPA 4 on ubuntu
Is there instructions anywhere? My FreeIPA 3 on CentOS died so I'm starting over -- 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] ntp and srv records
Hi All, Am about to start rolling out clinet installs on rhel6 hosts with dns autodiscovery. Enviroment: rhel6, ipa-3.0.0-37.el6. I already have setup SRV records for Kerberos and ldap etc. Are the following ntp records as SRV records necessary also? ;ntp server _ntp._udp IN SRV 0 100 123ntp1.mydomain.com. _ntp._udp IN SRV 0 100 123ntp2.mydomain.com. I've seen some guides that don't reference them, others that do. I don't see any adverse effects on the two freeipa servers (master + replica) that are currently running without the ntp srv records. Thanks in advance, Regards, Les -- 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] Install FreeIPA 4 on ubuntu
On 21.08.2014 04:27, Chris Whittle wrote: Is there instructions anywhere? My FreeIPA 3 on CentOS died so I'm starting over there is no server for ubuntu/debian yet -- t -- 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
