Unexpected ipa usa behaviour
by Ronald Wimmer
Hi,
in IPA I defined a user called isomeuser. This username does definitely
not exist on the AD side.
When I log in as root to an IPA client and issue the su command, I am
isomeuser(a)ad.domain. If I do "su isomeuser(a)ipa.domain" I am
isomeuser(a)ad.domain. The uid and gid are exactly the same.
Why can I be isomeuser(a)ad.domain if that user does not exist?
Regards,
Ronald
6 years, 5 months
Invalid ticket for NFS4 mount
by Raimund Eimann
Hi,
yesterday I noticed a strange issue on a Centos 7 client running
ipa-client-4.5.0-21.el7.centos.2.2.x86_64:
My daughter tried to log in to the machine and was kicked out again
after GNOME failed to load (/home on kerberized NFS4). Closer inspection
showed that she had no permission to access her home directory, so GNOME
was unable to read its settings.
This worked before.
I asked her to log into a text console. She got / as her home directory,
as again, she was unable to access her actual home directory.
I checked with klist that she got a ticket. All seemed fine there (TGT
present).
Tried 'cd' again: Permission denied.
Then I asked her to kinit once more. She hacken in her password again
and got a new ticket.
Tried 'cd' again, et voila!: It cding to her NFS4 home directory worked
immediately.
Questions:
- What could be the reason for this behaviour? The box was freshly
booted and I don't see what might have been wrong with the first ticket.
- Where should I look (which logs, etc.) to investigate this further?
Regards,
Ray
6 years, 5 months
Expired passwords and generating an OTP token
by Aaron Hicks
Hello the list,
I think this is the last thing to make our terrible user management model work.
With a helpdesk role via the REST API we can reset a users password, which is expired, because this is the right thing to do.
These users are expected to log into a node with 2FA using an OTP token generated by FreeIPA. This works if a user has a valid password and a token. This is the only machine they have access to, as it’s they lander node. They can not reach the FreeIPA web interface. They can use the FreeIPA API via our customer management system (CMS) either as them self or as a helpdek agent on their behalf. The CMS auth is SAML via federated shibboleth, so does not use our FreeIPA credentials.
However, we have few use cases we need to work:
Can a user generate an OTP token when their password is expired?
Can a a user reset their password when they do not have an OTP token?
Can a user reset their password when they can’t log in to get the secret from thier OTP token?
I think the shortest routes would be:
- if a user could reset an expired password via the FreeIPA API, then use the otptoken_add method to create one all via our CMS.
- if a user could reset thier password at the ssh login prompt if they have no token or don’t have thier token. Then add a token via our CMS.
Regards,
Aaron
Get Outlook for iOS<https://aka.ms/o0ukef>
6 years, 5 months
adding service
by Andrew Meyer
So i'm trying to add FreeRADIUS as a service to my IPA setup. I"ve added the service using --force and i'm trying to get the keytab for it but getting the following error:
[root@asm-rancid02 keytabs]# ipa-getkeytab -s asm-rancid02.mgt.asm.borg.local. -p radius/asm-rancid02.mgt.asm.borg.local -k /etc/krb5.keytabUnable to initialize STARTTLS sessionFailed to bind to server!Retrying with pre-4.0 keytab retrieval method...Unable to initialize STARTTLS sessionFailed to bind to server!Failed to get keytab[root@asm-rancid02 keytabs]#
Do I need to generate a keytab first? Should this be generated when I add the server to the domain/realm?
6 years, 5 months
Re: adding service
by Andrew Meyer
Not connecting to the FreeIPA server?
On Monday, November 20, 2017 4:36 PM, Robbie Harwood via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org> wrote:
Andrew Meyer via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
writes:
> [root@asm-rancid02 keytabs]# ipa-getkeytab -s asm-rancid02.mgt.asm.borg.local. -p radius/asm-rancid02.mgt.asm.borg.local -k /etc/krb5.keytab
> Unable to initialize STARTTLS session
> Failed to bind to server!
> Retrying with pre-4.0 keytab retrieval method...
> Unable to initialize STARTTLS session
> Failed to bind to server!
> Failed to get keytab
> [root@asm-rancid02 keytabs]#
>
> Do I need to generate a keytab first? Should this be generated when I
> add the server to the domain/realm?
This looks like it wasn't able to connect properly, so it hasn't reached
the point where Kerberos is involved.
Keytabs are generated when the machine is enrolled in the realm.
Thanks,
--Robbie
_______________________________________________
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
Server-Cert not found on setup-le.sh, does also not exist
by Matt .
I'm trying to install an Let's Encrypt certificate using the setup-le.sh script provides by the freeipa github repo.
It all goes fine but it finishes/stops with:
ipa: INFO: Systemwide CA database updated.
ipa.ipaclient.install.ipa_certupdate.CertUpdate: INFO: The ipa-certupdate command was successful
certutil: Server-Cert is neither a key-type nor a nickname: SEC_ERROR_BAD_DATABASE: security library: bad database.
In none of the Databases there is any Server-Cert named cert anymore, so what am I missing here ?
6 years, 5 months
freeIPA webUI failure after 4.5 upgrade on CentOS
by Chris Dagdigian
Did the "yum upgrade" followed by "sudo ipa-server-upgrade" followed by
a reboot on two different IPA servers
Now the webUI fails on both. The webUI error is:
Cannot connect to the server, please check API accesibility
(certificate, API, proxy, etc.)
httpd error log says this:
[Fri Nov 17 14:08:38.914506 2017] [:error] [pid 2748] ipa: INFO: ***
PROCESS START ***
[Fri Nov 17 14:08:39.002769 2017] [:error] [pid 2747] ipa: INFO: ***
PROCESS START ***
[Fri Nov 17 14:11:42.214284 2017] [auth_gssapi:error] [pid 2749] [client
172.29.128.180:54933] NO AUTH DATA Client did not send any
authentication headers, referer: https://usaeilidmp002.xxx.org/ipa/ui/
[Fri Nov 17 14:11:42.304960 2017] [auth_gssapi:error] [pid 2749] [client
172.29.128.180:54933] GSS ERROR In Negotiate Auth:
gss_accept_sec_context() failed: [An unsupported mechanism was requested
(Unknown error)], referer: https://usaeilidmp002.xxx.org/ipa/ui/
[root@usaeilidmp002 httpd]#
Browser is Chrome - same as I've always been using to access the admin UI
Any tips or guidance? May have to restore from backup
Chris
6 years, 5 months
Can't create new CA replica
by john.bowman@zayo.com
Since taking over our FreeIPA environment I've been unable to create a new CA replica. A bunch of failed attempts and upgrades over the last year and I keep running in to issues. After my latest attempt I noticed something that I had not seen before (likely a result of an recent upgrade) and I was wondering if this would cause a CA install to fail.
Our env:
3 x ipa-server-3.0.0-51.el6.x86_64
3 x ipa-server-4.4.0-14.el7_3.7.x86_64
2 of the 3.x IPA servers are currently acting as CAs and I've been trying to create a new 4.x CA replica in order to start removing the 3.x IPA servers. I've been able to do a simple test with vanilla CentOS 6.9 and 7.3 and it seems to work fine as far as I can tell but when I try it in our environment it fails. I noticed this error in one of the logs and something jumped out at me that I had never seen before:
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: === Finalization ===
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: Updating existing security domain
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: isSDHostDomainMaster(): Getting domain.xml from CA...
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: getting domain info
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: GET https://ipa-master.domain.tld:443/ca/admin/ca/getDomainXML
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: status: 0
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: domain info: <?xml version="1.0" encoding="UTF-8" standalone="no"?><DomainInfo><Name>IPA</Name><CAList><CA
><Host>ipa-master.domain.tld</Host><SecurePort>443</SecurePort><SecureAgentPort>443</SecureAgentPort><SecureAdminPort>443</SecureAdminPort><UnSecurePort>80</UnSecurePort><Sec
ureEEClientAuthPort>443</SecureEEClientAuthPort><DomainManager>TRUE</DomainManager><Clone>TRUE</Clone><SubsystemName>pki-cad</SubsystemName></CA><CA><Host>ipa-replica1.domain.tld
</Host><SecurePort>443</SecurePort><SecureAgentPort>443</SecureAgentPort><SecureAdminPort>443</SecureAdminPort><UnSecurePort>80</UnSecurePort><SecureEEClientAuthPort>443</S
ecureEEClientAuthPort><DomainManager>TRUE</DomainManager><Clone>TRUE</Clone><SubsystemName>pki-cad</SubsystemName></CA><CA><Host>ipa-replica2.domain.tld</Host><SecurePort>443</Se
curePort><SecureAgentPort>443</SecureAgentPort><SecureAdminPort>443</SecureAdminPort><UnSecurePort>80</UnSecurePort><SecureEEClientAuthPort>443</SecureEEClientAuthPort><Dom
ainManager>TRUE</DomainManager><Clone>TRUE</Clone><SubsystemName>pki-cad</SubsystemName></CA><SubsystemCount>3</SubsystemCount></CAList><OCSPList><SubsystemCount>0</Subsyst
emCount></OCSPList><KRAList><SubsystemCount>0</SubsystemCount></KRAList><RAList><SubsystemCount>0</SubsystemCount></RAList><TKSList><SubsystemCount>0</SubsystemCount></TKSL
ist><TPSList><SubsystemCount>0</SubsystemCount></TPSList></DomainInfo>
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: Cloning a domain master
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: Update security domain using admin interface
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: updateDomainXML start hostname=ipa-master.domain.tld port=443
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: POST https://ipa-master.domain.tld:443/ca/admin/ca/updateDomainXML
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: Unable to access admin interface: javax.ws.rs.NotFoundException: HTTP 404 Not Found
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: Update security domain using agent interface
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: updateDomainXML start hostname=ipa-master.domain.tld port=443
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: updateDomainXML() nickname=subsystemCert cert-pki-ca
[14/Jun/2017:06:49:44][http-bio-8443-exec-3]: ConfigurationUtils: POST https://ipa-master.domain.tld:443/ca/agent/ca/updateDomainXML
[14/Jun/2017:06:49:45][http-bio-8443-exec-3]: Server certificate:
[14/Jun/2017:06:49:45][http-bio-8443-exec-3]: - subject: CN=ipa-master.domain.tld,O=DOMAIN.US
[14/Jun/2017:06:49:45][http-bio-8443-exec-3]: - issuer: CN=Certificate Authority,O=DOMAIN.US
[14/Jun/2017:06:49:45][http-bio-8443-exec-3]: ConfigurationUtils: updateDomainXML: status=1
[14/Jun/2017:06:49:45][http-bio-8443-exec-3]: Unable to update security domain: 2
java.io.IOException: Unable to update security domain: 2
The ipa-master.domain.tld is one of the current RHEL 6.9 FreeIPA 3.x servers but the other two listed in that domainxml file one does not exist (it may have at some point been renamed) and the other server is not a CA replica but it is a replica.
Is it possible this bad info would cause a failure when trying to create a new CA replica? If so is it something I can try cleaning up?
Any info would be appreciated. Thanks!
6 years, 5 months
ipa-client-install (3.0.2 on Wheezy) fails after root certificate change via ipa-cacert-manage
by Harald Dunkel
Hi folks,
a few months ago I had replaced the externally signed root
certificate on my servers (CentOS 7.3) using ipa-cacert-manage.
Problem:
ipa-client-install on a freshly bootstrapped Debian 7 (Wheezy,
freeipa 3.0.2) fails. Apparently it stumbles over the old root
certificate:
# ipa-client-install --domain=example.de --realm=EXAMPLE.DE --no-ssh --no-sshd --no-ntp
Discovery was successful!
Hostname: pobde7i001.vs.example.de
Realm: EXAMPLE.DE
DNS Domain: example.de
IPA Server: ipa1.example.de
BaseDN: dc=example,dc=de
Continue to configure the system with these values? [no]: yes
User authorized to enroll computers: admin
Synchronizing time with KDC...
Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened.
Password for admin(a)EXAMPLE.DE:
Enrolled in IPA realm EXAMPLE.DE
Created /etc/ipa/default.conf
Domain example.de is already configured in existing SSSD config, creating a new one.
The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall.
Configured /etc/sssd/sssd.conf
Configured /etc/krb5.conf for IPA realm EXAMPLE.DE
trying https://ipa1.example.de/ipa/xml
cert validation failed for "CN=ipa1.example.de,O=example AG,C=DE" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.)
trying https://ipa2.example.de/ipa/xml
cert validation failed for "CN=ipa2.example.de,O=example AG,C=DE" ((SEC_ERROR_UNTRUSTED_ISSUER) Peer's certificate issuer has been marked as not trusted by the user.)
Cannot connect to the server due to generic error: cannot connect to Gettext('any of the configured servers', domain='ipa', localedir=None): https://ipa1.example.de/ipa/xml, https://ipa2.example.de/ipa/xml
Installation failed. Rolling back changes.
/etc/ipa/ca.crt on the client shows it somehow picked up the old
certificate. On the servers /etc/ipa/ca.crt is the new root cert.
"getcert list" on the servers shows only certificates based upon
the new root ca, too. I wonder where ipa-client-install picked up
the unwanted certificate?
Of course I tried putting the new ca.crt into place before running
ipa-client-install, but it was overwritten.
Of course there is no such problem for ipa 4.4.4 on Stretch.
Every heplful hint is highly appreciated
Harri
6 years, 5 months