What would be the way to configure a linux laptop free-ipa-client (sssd)
with freeipa users with otp (2fa) passwords, to keep working on other
networks then the local lan of the freeipa server?
Is there a sssd config option that can be used or port forwardings on
Jelle de Jong
We have one FreeIPA server and several clients. The ssh connection works well on clients, however this is not working on the server itslef.
I can use the default ssh user (outside of the FreeIPA), however when trying to use a FreeIPA user to login over SSH, I’m getting:
Invalid user xxxx from aaa.bbb.ccc.ddd
input_userauth_request: invalid user xxxx [preauth]
Connection closed by aaa.bbb.ccc.ddd port 64321 [preauth]
Any idea? Do we need to explicitly enable the FreeIPA clients login on the FreeIPA server?
Is there a possibility to get additional logs?
Two FreeIPA Idm Servers (1 Trust-Controller 1 Trust-Agent)
We ran into an issue were our Trust-Controller was offline and Kerberos authentication began failing for AD users. We do not allow interactive password auth. via sshd_config on IPA clients, only Pubkey or GSSAPI. From the clients we could resolve AD users without issue but AD user Kerberos authentication was failing with error regarding KDC not reachable.
Once we got the Trust-Controller back online, all was well and working again. Clearly our Trust-Controller was handling the KDC role in this use-case.
Example of klist output after Trust-Controller was back online. Hostnames/Users changed to protect the innocent of course.
Client: aduser @ AD-DOMAIN.COM
Server: host/ipaclient.freeipadomain.com @ FREEIPADOMAIN.COM
KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
Ticket Flags 0x40a90000 -> forwardable renewable pre_authent name_canonicalize 0x80000
Start Time: 4/29/2019 6:35:26 (local)
End Time: 4/29/2019 16:06:39 (local)
Renew Time: 5/6/2019 6:06:39 (local)
Session Key Type: AES-256-CTS-HMAC-SHA1-96
Cache Flags: 0
Kdc Called: freeipa-trust-controller.freeipadomain.com
My question is this; since we are only doing Kerberos auth for AD users, is it necessary we add the Trust-Agent to some/all MSDCS SRV records within FreeIPA DNS for this to work, in the event Trust-Controller is offline? It's been awhile since needing to dig into FreeIPA, so perhaps I am missing something.
Have had a small FreeIPA setup running for some time, but today I was unable to login at the web-gui on the master. It was possible to login at the replica but if try to delete a host I get:
cannot connect to 'https://ipa.int.vink-slott.dk:443/ca/rest/certs/search?size=2147483647': [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:877)
Indeed if I run a getcert list -c IPA on the master, one certificate is expired.
Request ID '20190302094604':
key pair storage: type=FILE,location='/var/lib/ipa/private/httpd.key'
issuer: CN=Certificate Authority,O=INT.VINK-SLOTT.DK
expires: 2019-04-22 15:33:08 CEST
key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
post-save command: /usr/libexec/ipa/certmonger/restart_httpd
All other certificates is valid and status: MONITORING
I tried different measures based on google searches and old entries on this list. But all I have accomplished is to change the state to:
Request ID '20190302094604':
key pair storage: type=FILE,location='/var/lib/ipa/private/httpd.key',pin set
At this state I am not sure that I added the correct pin. - And why this is suddenly a problem.
I have a user in our FreeIPA domain, whose password according to the applied policy (displayed in the user properties UI ) should have expired ~ 2 months ago, but it never did, nor did it force the user to reset it. The below LDAP user attributes show old data and all in accordance with the password policy. The user is still able to authenticate to the applications using LDAP connection against the FreeIPA servers. The krblastsuccessfulauth gets updated every time the user logs in. I assume if I force-reset the user’s password, it will go back to normal. However, I’d like to understand how to explain such a bizarre behavior and avoid it in the future.
User password expiration: 20190305034410Z
LEGAL DISCLAIMER: M.C. Dean, Inc. and its subsidiaries considers this e-mail and any files transmitted with it to be protected, proprietary or privileged information intended solely for the use of the named recipient(s). Any disclosure of this material or the information contained herein, in whole or in part, to anyone outside of the intended recipient or affiliates is strictly prohibited. M. C. Dean, Inc. accepts no liability for the content of this e-mail or for the consequences of any actions taken on the basis of the information contained in it, unless that information is subsequently confirmed in writing. Employees of M.C. Dean, Inc. are instructed not to infringe on any rights of the recipient; any such communication violates company policy. If you are not the intended recipient, any disclosure, copying, distribution, or action taken or omitted in reliance on this information is strictly prohibited by M.C. Dean, Inc.; please notify the sender immediately by return e-mail, delete this communication and destroy all copies.
We're seeing some strange gid assignment behavior. When I run ipa group-add
on one ipa client I get gids in the expected range for my domain (8000-10000).
But when it is run on one of our IPA servers we get numbers like 108500 or 58500.
ipa idrange-find reports what I would expect everywhere:
# ipa idrange-find
3 ranges matched
Range name: AD.NWRA.COM_id_range
First Posix ID of the range: 20000
Number of IDs in the range: 20000
First RID of the corresponding RID range: 0
Domain SID of the trusted domain: S-1-5-21-XXXX
Range type: Active Directory domain range
Range name: legacy
First Posix ID of the range: 1000
Number of IDs in the range: 100
First RID of the corresponding RID range: 10000
First RID of the secondary RID range: 100010000
Range type: local domain range
Range name: NWRA.COM_id_range
First Posix ID of the range: 8000
Number of IDs in the range: 2000
First RID of the corresponding RID range: 1000
First RID of the secondary RID range: 100000000
Range type: local domain range
Number of entries returned 3
No idea what else to look at.
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
We execute a script after any server creation that uses the FreeIPA API for adding the sever to the proper Hostgroup. As we already have the HBAC rules created with the hostgroups, the teams that should access to the servers are allowed automatically.