Re: How to Setup FreeIPA Services for Mac OS X 10.12
by David Harvey
Some edits and expansion on my previous attempt to post...
Free IPA 4.4.3
Mac OSX 10.12
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: Works If you also specify a real user in
the Directory Utility auth
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 directory 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.
From browsing my LDAP access logs it looks like only conventional binds are
attempted regardless. On the mac side it did until recently still mentions
GSSAPI attempts (when anonymous LDAP is disabled) although these couldn't
be found int he LDAP log. It feels like the Mac client is unable to work
out how to present the krb credential due to a mapping issue or DNS
discovery issue (both my IPA servers have RDNS entries).
Other notable log entries on the Mac side are " failed to retrieve password
for credential", and "failed to retrieve server schema". These both occur
under the rootdse only ldap config.
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.
Most of all I suppose I want to know what should work, or be workable!
Hope this makes sense, and thanks in advance,
David
p.s. I'm still not sure if I've managed to join this list, so subject to
moderation, and I might require an explicit reply to in order to get
responses!
6 years, 6 months
LDAP OTP Failure Using Interim BIND
by Callum Guy
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.
6 years, 6 months
7.4 upgrade fails with timeout exceeded
by Lachlan Musicman
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
6 years, 6 months
Type or value exists error
by Wanderley Teixeira
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:
6 years, 6 months
Re: Web UI - login failed after updates on server
by Stefan Uygur
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.fedoraho...
[Inline image 1]
6 years, 6 months
Authentication without OTP following upgrade to 4.5
by Callum Guy
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.
6 years, 6 months
Re: How to Setup FreeIPA Services for Mac OS X 10.12
by David Harvey
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!
6 years, 6 months
Could not chdir to home directory: Permission denied
by Wanderley Teixeira
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?
6 years, 6 months
Fwd: Authentication without OTP following upgrade to 4.5 (CentOS 7.4)
by Callum Guy
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.
6 years, 6 months