Enabling two-factor by host
by Aaron Hicks
Hello the list,
Is it possible to enable two-factor authentication using Google Authenticator on FreeIPA on specific hosts or groups of hosts?
Alternatively, are there any recommendations on modifying the Pam configuration on these 2FA required machines to grab the OTP token from FreeIPA when a user logs in?
Regards,
Aaron
Get Outlook for iOS<https://aka.ms/o0ukef>
6 years, 5 months
PWM and FreeIPA integration
by Aaron Hicks
Hello the FreeIPA List,
So as using the FreeIPA API and using LDAP directly to set existing users
passwords (because they don't yet have one) didn't work, we've set up PWM by
mostly following this gist:
https://gist.github.com/PowerWagon/d794a1233d7943f1614d2ae5223e678a
This has worked, and users with existing passwords can log in an manage
their passwords. We are not using it to create user accounts. However we
have some users who do not have passwords, so they can't provide a current
password to do a password change.
We have a page on our customer management system that allows users with no
password to enter a password and this is sent to the PWM REST interface to
set the user's password in FreeIPA. The user is not new, they just have no
password set. There's a couple of thousand of them, so we're really keen on
self service.
However when we send a password reset request to the PWM REST with the
setpassword command (using the pwmproxy user credentials) we get the
following response:
{"error":true,"errorCode":5027,"errorMessage":"You do not have permission to
perform the requested action."}
We've tried making the pwmproxy user a admin, and have giving them
permission to change users passwords with the System: Change User password
permission, however this gives the same response. I'd prefer not to give the
pwmproxy account admin, but we need this to work. We've also tried using the
admin account with the same results, we'd prefer to use an API key but have
not yet managed to authenticate with one.
I'm asking here as PWM is recommended by FreeIPA as a suitable 3rd Party
project https://www.freeipa.org/page/Self-Service_Password_Reset
I feel we're one step away from making this work. Is there a specific
permission, aci, or other hoop to jump through to allow PWM to set a user's
password?
Regards,
Aaron Hicks
6 years, 5 months
pointing SSSD/IPA at named AD domain controllers now with recent updates?
by Chris Dagdigian
The most fragile and user-angering aspect of our complex IPA setup in
AWS is when user AD password checks mysteriously fail and deny login.
All of the troubleshooting stuff works fine - user is recognized as
valid, ipa hbactest all work fine but the user gets permission denied
when logging in.
Right now my only fix is converting users over to SSH keybased logins
with the IPA server holding the public key -- that works great.
Restarting sssd a few times and waiting 10 minutes also usually resolves
the issue.
We *suspect* the password check failure is because this large
organization has 100+ domain controllers scattered in networks and
datacenters all over the place and we think that maybe SSSD is DNS
resolving via _SVR_ records a domain controller that is unreachable or
unknown to our cloud nACLs and security controls -- or maybe a domain
controller that just flat out refuses to talk to us.
I've seen on this list mentions of really cool AD integration
improvements like being able to have more than one AD domain vs the
existing "Default domain" that requires our users to login with fully
qualified <username>@<DOMAIN>.COMPANY.ORG as well as mentions that
future versions of SSSD would allow us to pin our communication to
known/named AD controllers? I think the basic advice from the IPA
community was that this stuff was showing up in modern sssd releases and
that we just had to wait a bit for the updated sssd code to show up in
distro repos.
Did I understand things correctly? Are we at the point now with IPA and
SSD upgrades where we could possibly pin our AD traffic to named
controllers? And maybe also address the AD domain search issue as well?
Thanks!
Chris
6 years, 5 months
Can't sync a new replica, large db file,
by Mike Johnson
Hi
I've got a small environment which had until recently 2 IPA servers.
Both CentOS 7.4.1708
Version info:
id1:
Name : ipa-server
Version : 4.5.0
Release : 21.el7.centos.2.2
Kernel: 3.10.0-693.5.2.el7.x86_64
389-ds-base is at version 1.3.6.1
id5:
Name : ipa-server
Version : 4.5.0
Release : 21.el7.centos.2.2
Kernel: 3.10.0-693.5.2.el7.x86_64
389-ds-base is at version 1.3.6.1
I recently had an issue with high IO/load, and noted that the following file:
/var/lib/dirsrv/slapd-PROD-MYDOMAIN-COM/cldb/<long-filename>.db
was huge (5GB-ish) in a very small 2-master environment. This is on
the master. My understanding is that the entries in this file, which
have timestamps from months ago, exist because of failed replication.
I don't understand how to clear this without breaking things.
Second issue; not sure if related:
I've since lost the replica (id2) but I've prepared a new machine
(id5) to be a new replica of id1. I've cleaned the RUVs and deleted
the replication agreements but when I join the new machine to the
existing one using `ipa-replica-install` then I get the following on
the replica:
################
Starting replication, please wait until this has completed.
Update in progress, 10 seconds elapsed
[ldap://id1.prod.mydomain.com:389] reports: Update failed! Status:
[-11 connection error: Unknown connection error (-11) - Total update
aborted]
[error] RuntimeError: Failed to start replication
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall):
ERROR Failed to start replication
ipa.ipapython.install.cli.install_tool(CompatServerReplicaInstall):
ERROR The ipa-replica-install command failed. See
/var/log/ipareplica-install.log for more information
[root@id5 ~]# ipa-replica-manage re-initialize --from id1.prod.mydomain.com
Re-run /usr/sbin/ipa-replica-manage with --verbose option to get more
information
Unexpected error: cannot connect to 'ldaps://id5.prod.mydomain.com:636':
################
and the following on the master:
################
[14/Nov/2017:10:05:28.671905981 +0000] - INFO - NSMMReplicationPlugin
- repl5_tot_run - Beginning total update of replica
"agmt="cn=meToid5.prod.mydomain.com" (id5:389)".
[14/Nov/2017:10:05:38.031033860 +0000] - ERR - NSMMReplicationPlugin -
repl5_tot_log_operation_failure - agmt="cn=meToid5.prod.mydomain.com"
(id5:389): Received error -1 (Can't contact LDAP server): for total
update operation
[14/Nov/2017:10:05:38.032272148 +0000] - ERR - NSMMReplicationPlugin -
release_replica - agmt="cn=meToid5.prod.mydomain.com" (id5:389):
Unable to send endReplication extended operation (Can't contact LDAP
server)
[14/Nov/2017:10:05:38.095893236 +0000] - ERR - NSMMReplicationPlugin -
repl5_tot_run - Total update failed for replica
"agmt="cn=meToid5.prod.mydomain.com" (id5:389)", error (-11)
[14/Nov/2017:10:05:38.113388624 +0000] - INFO - NSMMReplicationPlugin
- bind_and_check_pwp - agmt="cn=meToid5.prod.mydomain.com" (id5:389):
Replication bind with GSSAPI auth resumed
[14/Nov/2017:10:05:38.425682940 +0000] - WARN - NSMMReplicationPlugin
- repl5_inc_run - agmt="cn=meToid5.prod.mydomain.com" (id5:389): The
remote replica has a different database generation ID than the local
database. You may have to reinitialize the remote replica, or the
local replica.
################
I've checked the firewalls on both machines, and gone as far as to
flush all the iptables rules to get it to work. No luck.
I'm also getting hundreds of the last line "different database
generation ID" but my understanding is that this is only logged
because the replica is yet to be set up.
Would anyone please be able to provide some guidance? I've been at
this for a few days now!
Thanks!
MIke
6 years, 5 months
IPA & AD Domain Layout
by Justin Smith
I was tasked with setting up FreeIPA & Active Directory and connecting them with a trust relationship.
On FreeIPA 4.5, I created ipa.companydomain.com, set up an internal DNS zone for companydomain.com (which my company has used for both internal and external DNS - a bad practice, I know), and then tried to establish a trust relationship with Active Directory 2016. No dice. Alexander B. on here told me that AD does not expect that a forest can have a TLN which is superior to AD forest's root domain.
A Microsoft article on AD best practices recommends registering a public domain and then using a subdomain of that for internal purposes. That sounds sensible. Here's what I envision:
companyname.com (external sites + external DNS) -> corp.companyname.com (FreeIPA + intranet DNS) -> ad.corp.companyname.com (Active Directory domain)
Does that sound sensible? Just wanted to run it by someone else so I don't end up surprised again.
---
Justin Smith
IT Analyst
MIM Software, Inc.
[ https://www.mimsoftware.com/ | https://www.mimsoftware.com ]
6 years, 5 months
adding services to freeipa
by Andrew Meyer
When I try to add puppet i am getting the following error:
[andrew.meyer@asm-automation01 ~]$ ipa service-add puppetmaster/asm-automation01.mgt.asm.borg.localipa: ERROR: Host 'asm-automation01.mgt.asm.borg.local' does not have corresponding DNS A/AAAA record[andrew.meyer@asm-automation01 ~]$
I joined the server to the FreeIPA domain and there is an A record. Didn't check fro quad-A.
Not sure why it's throwing this error.
6 years, 5 months
FreeIPA server: Replication issues
by James Harrison
Hello,I am using Centos to host our FreeIPA servers. We have a CA-less setup.
I have upgraded to Centos 7.4 and FreeIPA version : VERSION: 4.5.0, API_VERSION: 2.228
The upgrade of both went off without any seen errors.
However, now I am getting the following messages on each server (12 in total): "ERR - attrlist_replace - attr_replace (nsslapd-referral" messages
Firstly, are these messages real problems I need to deal with?Secondly, if they are problems, how do I fix them? I have searched the internet and found lots of confusing mail threads, but no howto style document.
Thanks for any help.
Regards,James Harrison
6 years, 5 months
Re: ERROR: did not receive Kerberos credentials
by Carl Gola
Looks like it was finding kinit as part of java
I used the full path below but my personal ipa id generates an error but
the admin id works ok
[root@test-nfs-prod-1 ~]# rpm --info -qf $(which kinit)
file /opt/ibm/ibm-java-x86_64-8.0-1.10/jre/bin/kinit is not owned by any
package
[root@test-nfs-prod-1 ~]# find / -name kinit
/usr/bin/kinit
/usr/lib/jvm/java-1.8.0-ibm-1.8.0.4.10-1jpp.3.el7.x86_64/jre/bin/kinit
/opt/ibm/ibm-java-x86_64-8.0-1.10/jre/bin/kinit
[root@test-nfs-prod-1 ~]# rpm --info -qf /usr/bin/kinit
Name : krb5-workstation
Version : 1.15.1
Release : 8.el7
Architecture: x86_64
Install Date: Fri 27 Oct 2017 07:55:03 PM UTC
Group : System Environment/Base
Size : 2606453
License : MIT
Signature : RSA/SHA256, Wed 03 May 2017 09:39:47 AM UTC, Key ID
199e2f91fd431d51
Source RPM : krb5-1.15.1-8.el7.src.rpm
Build Date : Fri 28 Apr 2017 08:01:32 PM UTC
Build Host : x86-034.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor : Red Hat, Inc.
URL : http://web.mit.edu/kerberos/www/
Summary : Kerberos 5 programs for use on workstations
Description :
Kerberos is a network authentication system. The krb5-workstation
package contains the basic Kerberos programs (kinit, klist, kdestroy,
kpasswd). If your network uses Kerberos, this package should be
installed on every workstation.
[gola-us@test-nfs-prod-1 ~]$ /usr/bin/kinit gola-us
kinit: Client's entry in database has expired while getting initial
credentials
kinit with the admin id works ok
[root@test-nfs-prod-1 ~]# /usr/bin/kinit admin
Password for admin(a)test.LOCAL:
[root@test-nfs-prod-1 ~]# ipa user-find
----------------
70 users matched
----------------
User login: admin
Last name: Administrator
Home directory: /home/admin
etc..
Thanks,
Carl Gola
From: Robbie Harwood via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org>
To: Carl Gola <gola(a)us.ibm.com>, FreeIPA users list
<freeipa-users(a)lists.fedorahosted.org>
Cc: Robbie Harwood <rharwood(a)redhat.com>
Date: 11/15/2017 09:47 AM
Subject: [Freeipa-users] Re: ERROR: did not receive Kerberos credentials
"Carl Gola" <gola(a)us.ibm.com> writes:
> I'm not sure what's printing Done! either
>
> Here is a fresh kinit and klist afterwards
>
> [gola-us@test-nfs-prod-1 ~]$ kinit gola-us
> Password for gola-us(a)test.LOCAL:
>
> Done!
> New ticket is stored in cache file /home/rusers/gola-us/krb5cc_gola-us
> [gola-us@test-nfs-prod-1 ~]$ klist
>
> Credentials cache: /home/rusers/gola-us/krb5cc_gola-us
> Default principal: gola-us(a)test.LOCAL
> Number of entries: 1
>
> [1] Service principal: krbtgt/test.LOCAL(a)test.LOCAL
> Valid starting: Wednesday, November 15, 2017 at 4:03:26 PM
> Expires: Thursday, November 16, 2017 at 4:03:26 PM
Hmm, this doesn't look like MIT krb5; what is it? (
`rpm --info -qf $(which kinit)` or
`apt show $(dpkg -S $(which kinit) | awk -F: '{print $1}')` depending on
what OS you're on.)
Does Kerberos issue a service ticket as part of the user-find command,
or does it not get that far? (klist, and server logs will tell this.)
Thanks,
--Robbie
(See attached file: signature.asc)
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
6 years, 5 months
Re: ERROR: did not receive Kerberos credentials
by Carl Gola
I'm not sure what's printing Done! either
Here is a fresh kinit and klist afterwards
[gola-us@test-nfs-prod-1 ~]$ kinit gola-us
Password for gola-us(a)test.LOCAL:
Done!
New ticket is stored in cache file /home/rusers/gola-us/krb5cc_gola-us
[gola-us@test-nfs-prod-1 ~]$ klist
Credentials cache: /home/rusers/gola-us/krb5cc_gola-us
Default principal: gola-us(a)test.LOCAL
Number of entries: 1
[1] Service principal: krbtgt/test.LOCAL(a)test.LOCAL
Valid starting: Wednesday, November 15, 2017 at 4:03:26 PM
Expires: Thursday, November 16, 2017 at 4:03:26 PM
Thanks,
Carl Gola
From: Robbie Harwood via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org>
To: Carl Gola via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org>, FreeIPA users list
<freeipa-users(a)lists.fedorahosted.org>
Cc: Carl Gola <gola(a)us.ibm.com>, Robbie Harwood
<rharwood(a)redhat.com>
Date: 11/15/2017 08:58 AM
Subject: [Freeipa-users] Re: ERROR: did not receive Kerberos credentials
Carl Gola via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
writes:
> Receiving the following error when trying to run ipa commands
>
> [gola-us@test-nfs-prod-1 ~]$ kinit gola-us
> Password for gola-us(a)test.LOCAL:
>
> Done!
What's printing "Done!" here? kinit doesn't do that that I'm aware.
> New ticket is stored in cache file /home/rusers/gola-us/krb5cc_gola-us
What happens if you klist this file after kinit?
Thanks,
--Robbie
(See attached file: signature.asc)
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
6 years, 5 months
ERROR: did not receive Kerberos credentials
by Carl Gola
Receiving the following error when trying to run ipa commands
[gola-us@test-nfs-prod-1 ~]$ kinit gola-us
Password for gola-us(a)test.LOCAL:
Done!
New ticket is stored in cache file /home/rusers/gola-us/krb5cc_gola-us
[gola-us@test-nfs-prod-1 ~]$ ipa user-find
ipa: ERROR: did not receive Kerberos credentials
[gola-us@test-nfs-prod-1 ~]$
Linux version -
Red Hat Enterprise Linux Server release 7.3 (Maipo)
client
ipa-client-4.5.0-21.el7_4.2.2.x86_64
server
ipa-server-dns-4.5.0-21.el7_4.2.2.noarch
ipa-client-4.5.0-21.el7_4.2.2.x86_64
ipa-server-common-4.5.0-21.el7_4.2.2.noarch
ipa-server-4.5.0-21.el7_4.2.2.x86_64
ipa-server-trust-ad-4.5.0-21.el7_4.2.2.x86_64
ipa-common-4.5.0-21.el7_4.2.2.noarch
ipa-client-common-4.5.0-21.el7_4.2.2.noarch
If I change the location of the cache file - export
KRB5CCNAME=/tmp/.krb5cc-gola
I do a kinit gola-us and an ipa command returns this
[gola-us@test-nfs-prod-1 ~]$ kinit gola-us
Password for gola-us(a)test.LOCAL:
Done!
New ticket is stored in cache file /tmp/.krb5cc-gola
[gola-us@test-nfs-prod-1 ~]$ ipa user-find
ipa: ERROR: cannot connect to 'any of the configured servers':
https://test-ipa-prod-1.test.local/ipa/json,
https://test-ipa-prod-2.test.local/ipa/json
reviewing the krb5 logs shows normal communication between the client and
the ipa server. kerberos tickets are generated normally
Thanks,
Carl Gola
6 years, 5 months