FreeIPA, OSX, DockerDesktop
by james liu
PREP
====
git clone https://github.com/freeipa/freeipa-container.git
cd freeipa-container
mkdir /tmp/ipa-data
docker run --name freeipa-server-container -ti -h ipa.example.test --read-only -v /tmp/ip-data :/data:Z freeipa-server --sysctl net.ipv6.conf.all.disable_ipv6=1
RESULT
======
tar: etc/sysconfig/selinux: Cannot utime: No such file or directory
tar: Exiting with failure status due to previous errors
QUESTION
=========
I'm running DockerDesktop 2.0.4, OSX 10.13.6.
Is there a set of commands that will work?
Thanks
3 months
ipa-replica-install failing
by Mitchell Smith
Hi list,
I wanted to repost this issue with a more appropriate subject line, in
case anyone has come across this issue before and has a work around.
To provide some context, I have two FreeIPA instances running FreeIPA
4.3.1 on Ubuntu 16.04 LTS.
I want to migrate to FreeIPA 4.5.4 running on CentOS 7.
I have a way to migrate by dumping all the users out with ldapsearch
and adding them to the new instance with ldapadd but it is a bit messy
and will result in all users having to reset their password, as it
won't let me add in already encrypted passwords.
My initial thought was to add the new instance as a replica and then
eventually retire the old one.
I ran in to some problems with the ‘ipa-replica-install’ command though.
I was able to join as a client no problem, but when I went to run
‘ipa-replica-install’ it failed while configuring the directory server
component.
[25/42]: restarting directory server
[26/42]: creating DS keytab
[27/42]: ignore time skew for initial replication
[28/42]: setting up initial replication
[error] DatabaseError: Server is unwilling to perform: modification
of attribute nsds5replicareleasetimeout is not allowed in replica
entry
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
I thought this might have something to do with differences between
4.3.1 and 4.5.4 but I wasn’t entirely sure.
If there is a work around for this issue, it would be a significantly
easier transition to the new FreeIPA instance.
Cheers,
Mitch
4 months, 3 weeks
kinit -n asking for password on clients
by John Ratliff
When trying to do pkinit, if I do kinit -n on one of the IdM servers, it
works fine. If I try on a client machine, it asks me for the password
for WELLKNOWN/ANONYMOUS@REALM.
I have the pkinit_anchors setup for the realm. As I'm trying to do
anonymous pkinit, I think I don't need a client certificate.
On the server, I get this:
$ KRB5_TRACE="/dev/stderr" kinit -n
[13061] 1518402857.924212: Getting initial credentials for
WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM
[13061] 1518402857.929673: Sending request (200 bytes) to IDM.EXAMPLE.COM
[13061] 1518402857.931830: Initiating TCP connection to stream
10.77.9.101:88
[13061] 1518402857.932241: Sending TCP request to stream 10.77.9.101:88
[13061] 1518402857.939162: Received answer (359 bytes) from stream
10.77.9.101:88
[13061] 1518402857.939180: Terminating TCP connection to stream
10.77.9.101:88
[13061] 1518402857.939284: Response was from master KDC
[13061] 1518402857.939380: Received error from KDC:
-1765328359/Additional pre-authentication required
[13061] 1518402857.939474: Processing preauth types: 16, 15, 14, 136,
19, 147, 2, 133
[13061] 1518402857.939499: Selected etype info: etype aes256-cts, salt
"IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
[13061] 1518402857.939509: Received cookie: MIT
[13061] 1518402857.939563: Preauth module pkinit (147) (info) returned:
0/Success
[13061] 1518402857.940352: PKINIT client computed kdc-req-body checksum
9/D98A0144E7E4ACC66B63EBCA98379AB9F055D143
[13061] 1518402857.940369: PKINIT client making DH request
[13061] 1518402858.935: Preauth module pkinit (16) (real) returned:
0/Success
[13061] 1518402858.956: Produced preauth for next request: 133, 16
[13061] 1518402858.994: Sending request (1408 bytes) to IDM.EXAMPLE.COM
[13061] 1518402858.1091: Initiating TCP connection to stream 10.77.9.101:88
[13061] 1518402858.1187: Sending TCP request to stream 10.77.9.101:88
[13061] 1518402858.43063: Received answer (2880 bytes) from stream
10.77.9.101:88
[13061] 1518402858.43088: Terminating TCP connection to stream
10.77.9.101:88
[13061] 1518402858.43198: Response was from master KDC
[13061] 1518402858.43258: Processing preauth types: 17, 19, 147
[13061] 1518402858.43273: Selected etype info: etype aes256-cts, salt
"IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
[13061] 1518402858.43300: Preauth module pkinit (147) (info) returned:
0/Success
[13061] 1518402858.44150: PKINIT client verified DH reply
[13061] 1518402858.44189: PKINIT client found id-pkinit-san in KDC cert:
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM
[13061] 1518402858.44199: PKINIT client matched KDC principal
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM against id-pkinit-san; no EKU
check required
[13061] 1518402858.62345: PKINIT client used KDF 2B06010502030602 to
compute reply key aes256-cts/00E0
[13061] 1518402858.62395: Preauth module pkinit (17) (real) returned:
0/Success
[13061] 1518402858.62402: Produced preauth for next request: (empty)
[13061] 1518402858.62414: AS key determined by preauth: aes256-cts/00E0
[13061] 1518402858.62547: Decrypted AS reply; session key is:
aes256-cts/96F0
[13061] 1518402858.62589: FAST negotiation: available
[13061] 1518402858.62692: Initializing
KEYRING:persistent:760400007:krb_ccache_f3PFEy1 with default princ
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
[13061] 1518402858.62770: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM in
KEYRING:persistent:760400007:krb_ccache_f3PFEy1
[13061] 1518402858.62846: Storing config in
KEYRING:persistent:760400007:krb_ccache_f3PFEy1 for
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM: fast_avail: yes
[13061] 1518402858.62878: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krb5_ccache_conf_data/fast_avail/krbtgt\/IDM.EXAMPLE.COM\@IDM.EXAMPLE.COM(a)X-CACHECONF:
in KEYRING:persistent:760400007:krb_ccache_f3PFEy1
[13061] 1518402858.62933: Storing config in
KEYRING:persistent:760400007:krb_ccache_f3PFEy1 for
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM: pa_type: 16
[13061] 1518402858.62954: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krb5_ccache_conf_data/pa_type/krbtgt\/IDM.EXAMPLE.COM\@IDM.EXAMPLE.COM(a)X-CACHECONF:
in KEYRING:persistent:760400007:krb_ccache_f3PFEy1
But on the client, I get this:
$ KRB5_TRACE="/dev/stderr" kinit -n
[2941] 1518402820.155827: Getting initial credentials for
WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM
[2941] 1518402820.156298: Sending request (200 bytes) to IDM.EXAMPLE.COM
[2941] 1518402820.158723: Resolving hostname paine.example.com.
[2941] 1518402820.159975: Resolving hostname phantom.example.com.
[2941] 1518402820.160757: Resolving hostname paine.example.com.
[2941] 1518402820.161411: Initiating TCP connection to stream
204.89.253.101:88
[2941] 1518402820.162065: Sending TCP request to stream 204.89.253.101:88
[2941] 1518402820.168495: Received answer (359 bytes) from stream
204.89.253.101:88
[2941] 1518402820.168532: Terminating TCP connection to stream
204.89.253.101:88
[2941] 1518402820.169917: Response was from master KDC
[2941] 1518402820.169974: Received error from KDC:
-1765328359/Additional pre-authentication required
[2941] 1518402820.170029: Processing preauth types: 16, 15, 14, 136, 19,
147, 2, 133
[2941] 1518402820.170051: Selected etype info: etype aes256-cts, salt
"IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
[2941] 1518402820.170062: Received cookie: MIT
Password for WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM:
[2941] 1518402833.34612: Preauth module encrypted_timestamp (2) (real)
returned: -1765328252/Password read interrupted
kinit: Pre-authentication failed: Password read interrupted while
getting initial credentials
Suggestions on what I'm missing?
Thanks.
6 months, 1 week
IPA and legacy systems
by Ronald Wimmer
What would be a good solution to add systems where the FQDN cannot be
changed?
Would it make sense to add a second DNS A Record in the IPA domain for
each of these systems?
Is there any experience on how to deal with such a situation?
Thanks a lot in advance!
Cheers,
Ronald
7 months, 3 weeks
freeipa with sudo and 2FA (OTP)
by John Ratliff
I'm trying to setup freeipa with OTP. I created a TOTP under my user in
freeipa and updated my user to use 2FA (password + OTP).
When I try to do sudo, it only asks for my password and it fails every
time (presumably because it isn't getting the OTP first).
I didn't see anything useful in the sss_sudo logs, even after adding
debug_level = 6 in the config.
What can I do to further troubleshoot this?
Thanks.
10 months
Vault: Cannot authenticate agent with certificate
by Peter Oliver
I have a CentOS 7 server running ipa-server-4.5.4, recently installed. I find that operations related to the vault feature fail. For example:
> ipa -v vault-add test --type=standard
ipa: INFO: trying https://ipa-01.example.com/ipa/session/json
ipa: INFO: [try 1]: Forwarding 'vault_add_internal/1' to json server 'https://ipa-01.example.com/ipa/session/json'
ipa: INFO: [try 1]: Forwarding 'vault_show/1' to json server 'https://ipa-01.example.com/ipa/session/json'
ipa: INFO: [try 1]: Forwarding 'vaultconfig_show/1' to json server 'https://ipa-01.example.com/ipa/session/json'
ipa: INFO: [try 1]: Forwarding 'vault_archive_internal/1' to json server 'https://ipa-01.example.com/ipa/session/json'
ipa: ERROR: an internal error has occurred
In /var/log/pki/pki-tomcat/kra/system I see the following message:
0.ajp-bio-127.0.0.1-8009-exec-15 - [02/Nov/2018:14:54:37 GMT] [6] [3] Cannot authenticate agent with certificate Serial 0x7 Subject DN CN=IPA RA,O=IPA.EXAMPLE.COM. Error: User not found
In /var/log/pki/pki-tomcat/kra/debug is see the following messages:
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: SessionContextInterceptor: SystemCertResource.getTransportCert()
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: SessionContextInterceptor: Not authenticated.
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: AuthMethodInterceptor: SystemCertResource.getTransportCert()
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: AuthMethodInterceptor: mapping: default
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: AuthMethodInterceptor: required auth methods: [*]
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: AuthMethodInterceptor: anonymous access allowed
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: ACLInterceptor: SystemCertResource.getTransportCert()
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: ACLInterceptor.filter: no authorization required
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: ACLInterceptor: No ACL mapping; authz not required.
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: SignedAuditLogger: event AUTHZ
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: MessageFormatInterceptor: SystemCertResource.getTransportCert()
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: MessageFormatInterceptor: content-type: application/json
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: MessageFormatInterceptor: accept: [application/json]
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: MessageFormatInterceptor: request format: application/json
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-16]: MessageFormatInterceptor: response format: application/json
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: PKIRealm: Authenticating certificate chain:
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: PKIRealm.getAuditUserfromCert: certUID=CN=IPA RA, O=IPA.EXAMPLE.COM
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: PKIRealm: CN=IPA RA, O=IPA.EXAMPLE.COM
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: CertUserDBAuth: started
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: CertUserDBAuth: Retrieving client certificate
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: CertUserDBAuth: Got client certificate
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: Authentication: client certificate found
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: In LdapBoundConnFactory::getConn()
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: masterConn is connected: true
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: getConn: conn is connected true
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: getConn: mNumConns now 2
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: returnConn: mNumConns now 3
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: CertUserDBAuthentication: cannot map certificate to any userUser not found
[02/Nov/2018:14:54:37][ajp-bio-127.0.0.1-8009-exec-15]: SignedAuditLogger: event AUTH
Any suggestions? Has something gone wrong with the setup?
--
Peter Oliver
1 year, 4 months
Can login with non-existing user
by Ronald Wimmer
I have managed to login to an IPA client with a non-existing user.
My AD user is z123456(a)addomain.mydomain.at and I have created a similar
user called i123456(a)ipadomain.mydomain.at. What happened now is that I
could log in with the i-User and what I get to see after logging in is this:
[i123456@addomain.mydomain.at(a)as12314 ~]$ id
uid=1246600007(i123456(a)addomain.mydomain.at)
gid=1246600007(i123456(a)addomain.mydomain.at)
groups=1246600007(i123456@addomain.mydomain.at),1246600016(my-ad-group(a)ipadomain.mydomain.at)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[i123456@addomain.mydomain.at(a)as12314 ~]$ whoami
i123456(a)addomain.mydomain.at
The user i123456(a)addomain.mydomain.at does NOT exist.
addomain is set as default domain in the client's sssd.conf.
What is wrong here? Are things just displayed wrong or could it be more?
Which files do you need in order to analyze this issue?
Cheers,
Ronald
1 year, 4 months
FreeIPA v4.5.0 install lost topology suffixes
by Gavin Williams
Afternoon all
I’ve got a slightly strange one with one of our FreeIPA clusters, whereby the topology suffixes appear to have disappeared.
From what I can see, this is causing replication issues between the hosts, which is causing us issues with bootstrapping new clients against FreeIPA.
I’m not aware of any config changes that have happened on the FreeIPA hosts that could have caused this issue, so am a bit stumped atm.
Is someone able to advise next steps on how to investigate the cause and correct the configuration?
Regards
Gavin
1 year, 5 months
User in AD not found by IPA
by Marc Boorshtein
We added a new account to AD that has a domain trust with FreeIPA. This
one user is having an issue where IPA can't find him. The user is in the
same OU as other users that work fine. The user is unlocked
(userAccountControl is 512) and the userprincipalname is set. When I try
to add the user to an id view or an external group IPA gives me the error
"trusted domain object not found" . Not really sure where to look next to
figure out what's wrong. We see the user when we make LDAP calls to AD.
Thanks
Marc
1 year, 5 months
Intermitent AD atribute fetch
by Jo Domsic
Hi freeipa-users!
My IPA users occasionally report these issues:
1. Unable to login (failed pub key) via ssh on linux server
2. Missing shell (defaulted to sh, instead of bash or zsh) after ssh login on linux server
3. Missing home directory after ssh login on linux server
All of the users are present in ActiveDirectory (domain=ad.lan), and attributes are set (sshPublicKey and loginShell).
AD and FreeIPA are trusting each other. Linux servers are joined to domain (domain=ipa.lan).
I can confirm (1) fails when I run: /usr/bin/sss_ssh_authorizedkeys user(a)ad.lan. It returns empty. Repeated runs return the same result - nothing.
And both (2) and (3) happen without noticeable correlation to any other event.
I can confirm it by running getent passwd user(a)ad.lan. It displays some fields (either home folder or shell) as empty.
Issue (1) can be fixed with restarting sssd service and sss_cache -E.
Issue (2) mostly fixes itself after X amount of time (sometimes a minute, something an hour).
Issue (3) can be fixed same as (1), but sometimes also when repeating ssh connection (logout/login).
And as you might think: it's tiresome. :)
Does it make sense to you? Which logs would be most useful to get the bottom of this?
Note:
AD servers 2016
Freeipa version v4.6.4 (both servers and clients) on Centos 7.
1 year, 5 months