I'm looking for advice on the best way to tackle a problem I'm encountering. I
have a box which uses IPA/AD for authentication. SSH is running and open and
all users should be able to log in. The box sees quite a bit of malicious
access attempts - each of these attempts is having its (false)
I was able to accomplish this using the filter_users option in
/etc/sssd/sssd.conf. Thanks!
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of
I've seen similar situations in other threads, but searching for a solution
hasn't proven fruitful so far; please point me in the right direction! I've
configured an ipa server with a trusted AD domain and both lookups and
authentication are working on the server (I can getent and id AD users,
This is now working after adding a stanza for the AD realm in /etc/krb5.conf
file. Should that be necessary?
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
Also seems to be set:
freeipaclient$ dig +short -t SRV _kerberos._udp.cs.domain.dom
0 100 88 ipa.cs.domain.com.
freeipaclients$ dig +short -t SRV _kerberos._udp.domain.com
0 100 88 kdc1.domain.com.
0 100 88 kdc2.domain.com.
___
FreeIPA-users mailing
No, the lookups fail on both the server and the client.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
To the /etc/krb5.conf file on the client, I changed from this:
[realms]
CS.GRINNELL.EDU = {
kdc = ipa.cs.grinnell.edu:88
master_kdc = ipa.cs.grinnell.edu:88
admin_server = ipa.cs.grinnell.edu:749
kpasswd_server = ipa.cs.grinnell.edu:464
default_domain = cs.grinnell.edu
So you're saying the client is probably not finding the AD KDC through DNS SRV
calls? I think that I've tested all the DNS configs that are called for in the
documentation. What could I do to test whether the AD realm's KDC is being
discovered?
Here's what I've tried to see if the dns is
sssd_nss.log during attempted lookup of slyme...@grinnell.edu account:
https://pastebin.com/gLFnhZ9s
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora
Aha!
This (from the domain log) shed some light:
(Thu Jul 12 08:13:33 2018) [sssd[be[cs.grinnell.edu]]] [sdap_save_user]
(0x0400): Processing user slyme...@grinnell.edu
(Thu Jul 12 08:13:33 2018) [sssd[be[cs.grinnell.edu]]] [sdap_save_user]
(0x1000): Mapping user [slyme...@grinnell.edu]
I have an issue where i've established the AD trust and am able to lookup my
own account and about 30 others, but all others fail. I've compared AD
attributes across accounts and can't find anything that is notably different.
I've seen messages about making sure that groups can resolve, but I
I've configured FreeIPA with an AD trust that is handling workstation logins at
my organization. Things have been going well, but I've noticed a couple of
times that the Directory Services process is consuming a lot of CPU. This
morning, after receiving reports of users not being able to log
Thank you! The descriptions of the issue that I found do reflect what I
experienced:
https://pagure.io/389-ds-base/issue/49815
https://bugzilla.redhat.com/show_bug.cgi?id=1605554
DS Version: 389-ds-base-1.3.7.5-24.el7_5.x86_64
I've applied your recommended solution and will report back if the
The most useful bit of information I've found so far is this from the kadmind
log:
kadmind[14297](Error): Failed setting up a RPC socket (for 0.0.0.0.749)
kadmind: Address already in use - Error setting up network
I read that this can be caused by the rpcbind service taking over the port
I've had a FreeIPA installation running without issues until today directory
services went down and when I attempt to restart services using `ipactl
restart` the kadmin service fails to start. I've been digging through logs and
searching for answers but haven't found anything that makes sense
I decided to reboot the master and the services came back up without a problem.
Is it likely I was experiencing the bug that I linked earlier, and that just
restarting the rpcbind service isn't enough to free the port for kadmin to use?
___
Thanks for the reply.
I ran `nestat -tulpn` after restarting the rpcbind service and did not see
anything listening on 749. Unfortunately, I didn't think to run it before I
restarted the rpcbind service.
Is it possible kadmin think the port is in use even after rpcbind has moved off
it?
I have a one-way trust configured to AD. It has been working for a long time
but has stopped and I can't track down what has happened.
`getent passwd user` works on users in IPA, but fails (nothing returned) on AD
users.
Contents of sssd.conf on client:
[domain/ipa.domain.edu]
I'm afraid I don't know how to construct the right ipa-getkeytab command to
test. Do I run ipa-getkeytab on the client or on the ipa server? For the
IPA$@DOMAIN.EDU principal?
I thought about STARTTLS pointing to a certificate issue. The certs on the ipa
server are not expired:
getcert list |
The certificate for the AD secure ldap server is also current
(ad.domain.edu:636).
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct:
Thank you. I've run the following command on the broken client. In this
instance 'ipa.ipa.domain.edu' is the IPA server. 'IPA$@DOMAIN.EDU' was used
simply because it's what I saw in the logs.
KRB5CCNAME=/var/lib/sss/db/ccache_IPA.DOMAIN.EDU /usr/sbin/ipa-getkeytab -r -s
ipa.ipa.domain.edu -p
The following is a portion of the sssd log on the client reflecting the same
inability to retrieve keytab:
***
(Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state]
(0x1000): Domain domain.edu is Active
(Fri Feb 12 10:11:54 2021) [sssd[be[ipa.domain.edu]]]
This may be useful information: Clients are still able to lookup and
authenticate AD users as long as they have an in-tact cache. If I empty the
sssd cache, that client will no longer be able to perform AD lookups or
authentications.
___
FreeIPA-users
Thank you for the clarification. I ran in on the IPA server and the keytab was
successfully retrieved.
`Keytab successfully retrieved and stored in:
/var/lib/sss/keytabs/domain.edu.keytab-test`
-Mike
___
FreeIPA-users mailing list --
More logs. This is from another broken client during an attempt to login as an
AD user:
(Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state]
(0x1000): Domain domain.edu is Active
(Fri Feb 12 16:35:20 2021) [sssd[be[ipa.domain.edu]]] [sdap_id_op_connect_step]
Yes. I had modified sssd.conf on the server in pursuit of the solution to
proposed change and that is what caused this issue. I reverted the config and
authentication/lookups are now working as expected. I'd forgotten that I made
that change and since clients with in-tact caches were still
This additional bit from the logs indicates a failure to retireve a keytab:
(Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [main] (0x0400): Backend
provider (ipa.domain.edu) started!
(Thu Feb 11 15:45:13 2021) [sssd[be[ipa.domain.edu]]] [sss_domain_get_state]
(0x1000): Domain
27 matches
Mail list logo
