September 2017 - FreeIPA-users - Fedora mailing-lists

LDAP OTP Failure Using Interim BIND
by Callum Guy 20 Sep '17

20 Sep '17

Hi All, Since updating to CentOS 7.4/FreeIPA 4.5 (from 7.3/4.4) I have seen the following fault. IPA user accounts using password+OTP will authenticate *without OTP (only)* when using an interim LDAP BIND configuration. To clarify, I am specifically talking about Cisco ASA device, using a password only LDAP sysaccount bind user, using the binding to authenticate user VPN logins which all user password+OTP. Logins are only authenticated when no OTP is present. All other authentications (SSSD/UI) for the same user work normally and enforce the use of the appended OTP code. Does anyone have any ideas for debugging this situation? Thanks, Callum -- Callum Guy Head of Information Security X-on -- *0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk> | ** <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments.

1 0

7.4 upgrade fails with timeout exceeded
by Lachlan Musicman 20 Sep '17

20 Sep '17

2017-09-19T22:30:50Z DEBUG wait_for_open_ports: localhost [8080, 8443] timeout 300 2017-09-19T22:35:51Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2017-09-19T22:35:51Z DEBUG File "/usr/lib/python2.7/site- packages/ipapython/admintool.py", line 172, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 46, in run server.upgrade() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1913, in upgrade upgrade_configuration() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1652, in upgrade_configuration ca.start('pki-tomcat') File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 401, in start self.service.start(instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 211, in start instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py", line 300, in start self.wait_for_open_ports(self.service_instance(instance_name)) File "/usr/lib/python2.7/site-packages/ipaplatform/base/services.py", line 270, in wait_for_open_ports self.api.env.startup_timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1227, in wait_for_open_ports raise socket.timeout("Timeout exceeded") 2017-09-19T22:35:51Z DEBUG The ipa-server-upgrade command failed, exception: timeout: Timeout exceeded 2017-09-19T22:35:51Z ERROR Timeout exceeded 2017-09-19T22:35:51Z ERROR The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information How do I fix? Is there a patch available? This process went smoothly in testing, so I rolled out to prod. We need this up and running. cheers L. ------ "The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics is the insistence that we cannot ignore the truth, nor should we panic about it. It is a shared consciousness that our institutions have failed and our ecosystem is collapsing, yet we are still here — and we are creative agents who can shape our destinies. Apocalyptic civics is the conviction that the only way out is through, and the only way through is together. " *Greg Bloom* @greggish https://twitter.com/greggish/status/873177525903609857

3 7

IPA Vault Feature
by Ronald Wimmer 20 Sep '17

20 Sep '17

Hi, I read about the vault feature in the documentation and installed the feature on my ipa master (ipa-kra-install). However, when I try to access my vault on an ipa client, I get: ipa: INFO: trying https://ipa2.linux.mydomain.at/ipa/session/json ipa: INFO: trying https://ipa2.linux.mydomain.at/ipa/session/json ipa: INFO: Connection to https://ipa2.linux.mydomain.at/ipa/session/json failed with <ProtocolError for ipa2.linux.mydomain.at/ipa/session/json: 401 Unauthorized> ipa: INFO: trying https://ipa1.linux.mydomain.at/ipa/session/json ipa: INFO: Connection to https://ipa1.linux.mydomain.at/ipa/session/json failed with <ProtocolError for ipa1.linux.mydomain.at/ipa/session/json: 401 Unauthorized> ipa: ERROR: cannot connect to 'any of the configured servers': https://ipa2.linux.mydomain.at/ipa/session/json, https://ipa1.linux.mydomain.at/ipa/session/json What is wrong here? Am I misunderstanding the concept (centralized vault on ipa servers being accessable by ipa clients)? Regards, Ronald

1 0

Type or value exists error
by Wanderley Teixeira 19 Sep '17

19 Sep '17

Trying to change the Title field of a user in a POSIX group via the GUI throws this error: IPA Error 4203: DatabaseError Type or value exists:

1 0

Do keytabs expire?
by Ronald Wimmer 19 Sep '17

19 Sep '17

Hi, today I found out that some entries in a keytab file seemed to have expired: Request ticket server HTTP/mwc.linux.mydomain.at(a)LINUX.MYDOMAIN.AT kvno 4 not found in keytab; keytab is likely out of date Fetching the keytab again with ipa-getkeytab fixed the problem. But why is this happening? Do keytab entries expire? I have not set any custom password or ticket policies. Regards, Ronald

2 8

Re: Web UI - login failed after updates on server
by Stefan Uygur 19 Sep '17

19 Sep '17

Hi Mike, Not sure if you are having the same problem as myself. What I had basically was that the system somehow got messed the packages of current and new upgrade versions. Basically after upgrade I found both previous and new packages (dupes) installed along. So first thing I cleaned up all dupes and re-do the update. That helped to return IPA web UI but still was having issues with login. I noticed I had host entry for IPA server itself (/etc/hosts) and I just removed that then I was able to login. Another thing you might lookup for can be apache rewrite rules, that upgrade messed that too. Let me know how you are getting on. Stefan From: mike jazz [mailto:mike.jazz101@gmail.com] Sent: 19 September 2017 03:23 To: Stefan Uygur Subject: Web UI - login failed after updates on server Hi Stefan, How are you doing today? I need some help regarding about freeIPA. After I'm upgrading yum update on CentOS 7 and try login Web UI freeIPA keep complaining "Login failed due to an unknown reason." How do you resolve the issue by removing the host? Maybe you can help me. Thank you. https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… [Inline image 1]

1 0

Authentication without OTP following upgrade to 4.5
by Callum Guy 19 Sep '17

19 Sep '17

Hi All, I have recently applied the CentOS 7.4 updates which includes installation of FreeIPA 4.5. Prior to the update we were running CentOS 7.3 (the original OS for this system) and FreeIPA 4.4 and the platform has been regularly updated without issue. We operate a master and replica pair at a single location. Since upgrading to FreeIPA 4.5 user authentication is behaving inconsistently with relation to OTP - we use password+OTP for all user authentication. Our platform is available behind a VPN provided by a Cisco ASA where the authentication is handled by FreeIPA using an interim LDAP bind on a dedicated system account (i.e. https://www.freeipa.org/page/HowTo/LDAP). Since the update *this connection does not accept OTP* tokens but does work with password only - in contrast with our security policy. Once connected the user can then SSH into the system - for this connection the normal authentication (password+otp) works - password only does not work here. With an SSH session to the IPA master I can run ldapsearch and authenticate with password+otp only. The web UI also requires password+otp. To clarify the system should not accept any user logins using password only and the acceptance of this on our VPN connection quite concerning. Is anyone able to offer advice on how to dig deeper and resolve the issue? Some system details: --- $ sudo ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING httpd Service: RUNNING ipa-custodia Service: RUNNING ntpd Service: RUNNING pki-tomcatd Service: RUNNING ipa-otpd Service: RUNNING ipa-dnskeysyncd Service: RUNNING ipa: INFO: The ipactl command was successful $ sudo rpm -qa| grep ipa ipa-common-4.5.0-21.el7.centos.1.2.noarch ipa-server-dns-4.5.0-21.el7.centos.1.2.noarch ipa-python-compat-4.5.0-21.el7.centos.1.2.noarch ipa-client-common-4.5.0-21.el7.centos.1.2.noarch ipa-client-4.5.0-21.el7.centos.1.2.x86_64 ipa-server-4.5.0-21.el7.centos.1.2.x86_64 python-libipa_hbac-1.15.2-50.el7_4.2.x86_64 python2-ipaserver-4.5.0-21.el7.centos.1.2.noarch sssd-ipa-1.15.2-50.el7_4.2.x86_64 python2-ipaclient-4.5.0-21.el7.centos.1.2.noarch libipa_hbac-1.15.2-50.el7_4.2.x86_64 python2-ipalib-4.5.0-21.el7.centos.1.2.noarch ipa-server-common-4.5.0-21.el7.centos.1.2.noarch -- There is an additional "symptom" present on the web UI - every visit to the login screen now gets two HTTP BASIC authentication pop-ups - typically we would just get one and dismiss it to proceed to normal logon. Not sure if that is at all relevant. Each popup appears in the apache error log as separate GSSAPI errors - shown below. Not a problem, just different. -- [Mon Sep 18 14:09:07.974254 2017] [auth_gssapi:error] [pid 7810] [client 172.18.0.1:53298] NO AUTH DATA Client did not send any authentication headers, referer: https://pci-fram-ipa1.domain.net/ipa/ui/ [Mon Sep 18 14:09:09.712143 2017] [auth_gssapi:error] [pid 3101] [client 172.18.0.1:53304] NO AUTH DATA Client did not send any authentication headers, referer: https://pci-fram-ipa1.domain.net/ipa/ui/ -- Thanks, Calllum -- Callum Guy Head of Information Security X-on -- *0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk> | ** <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments.

1 0

Re: How to Setup FreeIPA Services for Mac OS X 10.12
by David Harvey 18 Sep '17

18 Sep '17

Thanks for all the hard work on this, I've been enjoying an almost functional setup for the last week but have been tearing my hair out with making GSSAPI behave. What I have found so far using the config instructions - may be error prone now as the number of combinations tried! Anonymous bind enabled on freeipa: all works fine as you would expect. RootDSE only enabled on freeipa : Works If you also specify a real user in the Directory Utility auth section (not a service account) No anonymous binds : Will not play at all. Now the thing that is really throwing me, is that GSSAPI ldapsearch works just fine from the command line (using -Y GSSAPI) but directiory utility seems unable to use these credentials. I'm totally unsure if this is an OS limitation (as the login screen wouldn't have any creds until a user has typed them) or if I've managed to screw something up. I'd like to be in a position where I can either have a very reduced access LDAP user enabled on all Mac clients, or that they can harness the host or user keytab in order to require no special LDAP credentials of their own. Hope this makes sense, and thanks in advance, David p.s. I've attempted to and failed to join this list, so subject to moderation, and I might require an explicit reply to in order to get responses!

1 0

Could not chdir to home directory: Permission denied
by Wanderley Teixeira 18 Sep '17

18 Sep '17

I installed the server and client (with --mkhomedir) without issues. I created a user and tried to ssh and got this error creating directory ssh user1(a)ipaclient1.int.example.com Password: Could not chdir to home directory /home/user1: Permission denied -sh: /home/user1/.profile: Permission denied -sh-4.2$ Any idea what the problem could be here?

3 2

Fwd: Authentication without OTP following upgrade to 4.5 (CentOS 7.4)
by Callum Guy 18 Sep '17

18 Sep '17

Hi All, I have recently applied the CentOS 7.4 updates which includes installation of FreeIPA 4.5. Prior to the update we were running CentOS 7.3 (the original OS for this system) and FreeIPA 4.4 and the platform has been regularly updated without issue. We operate a master and replica pair at a single location. Since upgrading to FreeIPA 4.5 user authentication is behaving inconsistently with relation to OTP - we use password+OTP for all user authentication. Our platform is available behind a VPN provided by a Cisco ASA where the authentication is handled by FreeIPA using an interim LDAP bind on a dedicated system account (i.e. https://www.freeipa.org/page/HowTo/LDAP). Since the update *this connection does not accept OTP* tokens but does work with password only - in contrast with our security policy. Once connected the user can then SSH into the system - for this connection the normal authentication (password+otp) works - password only does not work here. With an SSH session to the IPA master I can run ldapsearch and authenticate with password+otp only. The web UI also requires password+otp. To clarify the system should not accept any user logins using password only and the acceptance of this on our VPN connection quite concerning. Is anyone able to offer advice on how to dig deeper and resolve the issue? Some system details: --- $ sudo ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING httpd Service: RUNNING ipa-custodia Service: RUNNING ntpd Service: RUNNING pki-tomcatd Service: RUNNING ipa-otpd Service: RUNNING ipa-dnskeysyncd Service: RUNNING ipa: INFO: The ipactl command was successful $ sudo rpm -qa| grep ipa ipa-common-4.5.0-21.el7.centos.1.2.noarch ipa-server-dns-4.5.0-21.el7.centos.1.2.noarch ipa-python-compat-4.5.0-21.el7.centos.1.2.noarch ipa-client-common-4.5.0-21.el7.centos.1.2.noarch ipa-client-4.5.0-21.el7.centos.1.2.x86_64 ipa-server-4.5.0-21.el7.centos.1.2.x86_64 python-libipa_hbac-1.15.2-50.el7_4.2.x86_64 python2-ipaserver-4.5.0-21.el7.centos.1.2.noarch sssd-ipa-1.15.2-50.el7_4.2.x86_64 python2-ipaclient-4.5.0-21.el7.centos.1.2.noarch libipa_hbac-1.15.2-50.el7_4.2.x86_64 python2-ipalib-4.5.0-21.el7.centos.1.2.noarch ipa-server-common-4.5.0-21.el7.centos.1.2.noarch -- There is an additional "symptom" present on the web UI - every visit to the login screen now gets two HTTP BASIC authentication pop-ups - typically we would just get one and dismiss it to proceed to normal logon. Not sure if that is at all relevant. Each popup appears in the apache error log as separate GSSAPI errors - shown below. Not a problem, just different. -- [Mon Sep 18 14:09:07.974254 2017] [auth_gssapi:error] [pid 7810] [client 172.18.0.1:53298] NO AUTH DATA Client did not send any authentication headers, referer: https://pci-fram-ipa1.domain.net/ipa/ui/ [Mon Sep 18 14:09:09.712143 2017] [auth_gssapi:error] [pid 3101] [client 172.18.0.1:53304] NO AUTH DATA Client did not send any authentication headers, referer: https://pci-fram-ipa1.domain.net/ipa/ui/ -- Thanks, Calllum -- Callum Guy Head of Information Security X-on -- Callum Guy Head of Information Security X-on -- *0333 332 0000 | www.x-on.co.uk <http://www.x-on.co.uk> | ** <https://www.linkedin.com/company/x-on> <https://www.facebook.com/XonTel> <https://twitter.com/xonuk> * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland House, 110 London Road, Apsley, Hemel Hempstead, Herts, HP3 9SD. Company Registration No. 2578478. The information in this e-mail is confidential and for use by the addressee(s) only. If you are not the intended recipient, please notify X-on immediately on +44(0)333 332 0000 and delete the message from your computer. If you are not a named addressee you must not use, disclose, disseminate, distribute, copy, print or reply to this email. Views or opinions expressed by an individual within this email may not necessarily reflect the views of X-on or its associated companies. Although X-on routinely screens for viruses, addressees should scan this email and any attachments for viruses. X-on makes no representation or warranty as to the absence of viruses in this email or any attachments.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users September 2017