Unable to install ipa client centos 7.5.1804 (Core)
by William Graboyes
Hello List,
I have been searching around for the day and have found an answer for
the error I am getting when I am trying to install the client on a brand
new install:
Version:
ipa-client-4.5.4-10.el7.centos.3.x86_64
ipa-client-common-4.5.4-10.el7.centos.3.noarch
The error is below (run as root, not via sudo):
ipa-client-install
Traceback (most recent call last):
File "/sbin/ipa-client-install", line 22, in <module>
from ipaclient.install import ipa_client_install
File
"/usr/lib/python2.7/site-packages/ipaclient/install/ipa_client_install.py",
line 5, in <module>
from ipaclient.install import client
File "/usr/lib/python2.7/site-packages/ipaclient/install/client.py",
line 34, in <module>
from ipalib import api, errors, x509
File "/usr/lib/python2.7/site-packages/ipalib/x509.py", line 45, in
<module>
from pyasn1_modules import rfc2315, rfc2459
File "/usr/lib/python2.7/site-packages/pyasn1_modules/rfc2315.py",
line 67, in <module>
class DigestedData(univ.Sequence):
File "/usr/lib/python2.7/site-packages/pyasn1_modules/rfc2315.py",
line 72, in DigestedData
namedtype.NamedType('digest', Digest)
File "/usr/lib/python2.7/site-packages/pyasn1/type/namedtype.py",
line 115, in __init__
self.__ambiguousTypes = 'terminal' not in kwargs and
self.__computeAmbiguousTypes() or {}
File "/usr/lib/python2.7/site-packages/pyasn1/type/namedtype.py",
line 232, in __computeAmbiguousTypes
ambigiousTypes[idx] = NamedTypes(*partialAmbigiousTypes,
**dict(terminal=True))
File "/usr/lib/python2.7/site-packages/pyasn1/type/namedtype.py",
line 114, in __init__
self.__tagToPosMap = self.__computeTagToPosMap()
File "/usr/lib/python2.7/site-packages/pyasn1/type/namedtype.py",
line 205, in __computeTagToPosMap
for _tagSet in tagMap.presentTypes:
AttributeError: 'property' object has no attribute 'presentTypes'
Any help would be greatly appreciated.
Thanks,
Bill G.
2 weeks, 2 days
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
4 months, 3 weeks
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
6 months, 1 week
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.
7 months, 3 weeks
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
9 months, 1 week
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.
11 months, 2 weeks
Force users to create OTP token on first login
by Russ Long
Is there a way to put a policy or something in place, so when users login for the first time, they are forced to create an OTP Token? We need to force OTP into the system as well as the servers that authenticate with it.
Thanks!
1 year, 4 months
Re: CA Master Confusion
by Florence Blanc-Renaud
On 8/6/19 9:21 PM, Auerbach, Steven via FreeIPA-users wrote:
> As I work through understanding the current state of my CA mastering in this realm I am getting results I do not understand from these ipa commands (on the v4.6.4 server) and from the ldapsearch commands (on the v3.0.0 server):
> On the v4.6.4 replica (ipa<3>):
> $ sudo ipa config-show |grep 'CA renewal master'
> [sudo] password for <user>:
> $
> $
>
> On the v3.0.0 (ipa<1>):
> $ sudo ldapsearch -H ldap://$HOSTNAME -D 'cn=Directory Manager' -W -b 'cn=masters,cn=ipa,cn=etc,dc=fbog,dc=local' '(&(cn=CA)(ipaConfigString=caRenewalMaster))' dn
> [sudo] password for <user>:
> Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base <cn=masters,cn=ipa,cn=etc,dc=<mydomain>,dc=local> with scope subtree
> # filter: (&(cn=CA)(ipaConfigString=caRenewalMaster))
> # requesting: dn
> #
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 1
>
Hi,
the ipaConfigString=caRenewalMaster attribute was introduced in freeIPA
4.0 (please see [1] Howto/Promote_CA_to_Renewal_and_CRL_Master), hence I
am not surprised that the search does not return anything.
When the 3.0 server was installed, the attribute did not exist yet. When
the 4.x replica was installed, the attribute was not added since the new
replica wasn't CA master.
As the attribute is not set at all, the ipa config-show command
(internally using the same ldapsearch you did) is unable to find a CA
master.
If you want to move the CA master role to ipa3, just follow the steps in
[1], making sure to apply the steps for the corresponding IPA version.
Also please note that we do not recommend using versions 3.x and 4.x
together over a long period of time. This is completely OK when you want
to migrate but once you have ensured all the services are properly
working, the 3.x master should be decommissioned. Please see [2].
HTH,
flo
[1] https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master
[2]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
>
>
> Neither tells me anything. Is it possible that the original installation never had a CA master at all? This seems odd considering when I look for CA Master(s), on the v4.6.4 (ipa<3>) tells me:
>
> $ sudo ipa server-role-find --role 'CA server'
> [sudo] password for <user>:
> ----------------------
> 3 server roles matched
> ----------------------
> Server name: ipa<2>.mydomain.local
> Role name: CA server
> Role status: absent
>
> Server name: ipa<1>.mydomain.local
> Role name: CA server
> Role status: enabled
>
> Server name: ipa<3>.mydomain.local
> Role name: CA server
> Role status: absent
> ----------------------------
> Number of entries returned 3
> ----------------------------
>
> And on the v3.0.0 (ipa<1>) I get:
>
> $ sudo ldapsearch -H ldap://$HOSTNAME -D 'cn=Directory Manager' -W -b 'cn=masters,cn=ipa,cn=etc,dc=<mydomain>,dc=local' '(&(cn=CA)(ipaConfigString=caServer))' dn
> Enter LDAP Password:
> # extended LDIF
> #
> # LDAPv3
> # base <cn=masters,cn=ipa,cn=etc,dc=fbog,dc=local> with scope subtree
> # filter: (&(cn=CA)(ipaConfigString=caServer))
> # requesting: dn
> #
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 1
>
> I know I am missing something basic and fundamental here. Is there a CA Master or not? If not, would I want to just enable the CA Master on the newest server (ipa<3>)?
>
> The way forward is not clear.
> -Steven Auerbach
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>
1 year, 5 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, 5 months
Unable to add external domain global groups
by Martijn Bakkes
We have a one way trust set up on our IPA with our AD. ( IPA trusting AD ).
I am able to add domain local groups as external member is an IPA group.
However, when I try to add a domain global group I receive the error:
invalid 'trusted domain object': no trusted domain matched the specified flat name
Has anybody run in to this issue. I can only find this error referenced in cases where the trust wasn't working.
1 year, 6 months