Somehow, the admin account is permanently locked
just a simple reproduction
sh-4.2# kinit admin kinit: Client's credentials have been revoked while getting initial credentials
sh-4.2# kdestroy -A
sh-4.2# kinit <another admin> Password for <another admin>@bla-bla
sh-4.2# ipa user-unlock admin ------------------------ Unlocked account "admin" ------------------------
sh-4.2# kdestroy -A
sh-4.2# kinit admin Password for admin@bla-bla
sh-4.2# kdestroy -A
sh-4.2# kinit admin kinit: Client's credentials have been revoked while getting initial credentials
And this is apparently related to the previous issue which still persists https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Nothing suspicious in the logs or i'm looking at wrong logs.
Any ideas please assist, thanks.
On ti, 03 heinä 2018, skrawczenko--- via FreeIPA-users wrote:
Somehow, the admin account is permanently locked
just a simple reproduction
sh-4.2# kinit admin kinit: Client's credentials have been revoked while getting initial credentials
sh-4.2# kdestroy -A
sh-4.2# kinit <another admin> Password for <another admin>@bla-bla
sh-4.2# ipa user-unlock admin
Unlocked account "admin"
sh-4.2# kdestroy -A
sh-4.2# kinit admin Password for admin@bla-bla
sh-4.2# kdestroy -A
sh-4.2# kinit admin kinit: Client's credentials have been revoked while getting initial credentials
And this is apparently related to the previous issue which still persists https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Nothing suspicious in the logs or i'm looking at wrong logs.
Any ideas please assist, thanks.
You need to look at /var/log/krb5kdc.log on each master.
Well ok, further observation.
Not much to see in krb5kdc.log, just same 'revoked credentials' for admin
However
When looking at ipa user-status admin after ipa user-unlock admin, i can see the Failed logins are increasing to 6 whithin 5-10 seconds. Same happening on both masters, ipa user-unlock admin, then 1,2..6 failed logins within few seconds.
What can cause those failed logins in theory and where it can be logged please advise?
Thanks a lot
On to, 05 heinä 2018, skrawczenko--- via FreeIPA-users wrote:
Well ok, further observation.
Not much to see in krb5kdc.log, just same 'revoked credentials' for admin
However
When looking at ipa user-status admin after ipa user-unlock admin, i can see the Failed logins are increasing to 6 whithin 5-10 seconds. Same happening on both masters, ipa user-unlock admin, then 1,2..6 failed logins within few seconds.
something probes login as admin? You should have in krb5kdc.log an indication of the client IP address. Where that points to?
We have a number of systems on the internet. They are constantly attacked through ssh. A lot of attacks try to guess passwords for a user called “admin.” It’s a high enough volume that our admin is always locked. When I need to do something as admin I have to disable attack lockout temporarily. Fortunately that’s uncommon, since we normally use users in the admins group rather than the actual admin user.
On Jul 5, 2018, at 8:39 AM, Alexander Bokovoy via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
On to, 05 heinä 2018, skrawczenko--- via FreeIPA-users wrote:
Well ok, further observation.
Not much to see in krb5kdc.log, just same 'revoked credentials' for admin
However
When looking at ipa user-status admin after ipa user-unlock admin, i can see the Failed logins are increasing to 6 whithin 5-10 seconds. Same happening on both masters, ipa user-unlock admin, then 1,2..6 failed logins within few seconds.
something probes login as admin? You should have in krb5kdc.log an indication of the client IP address. Where that points to?
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahost...
hedrick--- via FreeIPA-users freeipa-users@lists.fedorahosted.org writes:
We have a number of systems on the internet. They are constantly attacked through ssh. A lot of attacks try to guess passwords for a user called “admin.”
If you don't need the user admin on the outside facing boxes, you could try that in /etc/sss/sssd.conf:
,---- | ... | [nss] | homedir_substring = /home | filter_users = root, admin | ... `----
Jochen
Unfortunately, can't see anything suspicious in krb5kdc.log Multiple hosts request TGT in NEEDED_PREAUTH:host/<hostname> - ISSUE dialogs.
No errors and 'admin' is not encountered anywhere.
I'm having a concern that older machines could have been enrolled (ipa-client) with admin user. Could you suggest where i can check this setting on the client machines and modify if needed? Thanks.
On ke, 11 heinä 2018, skrawczenko--- via FreeIPA-users wrote:
Unfortunately, can't see anything suspicious in krb5kdc.log Multiple hosts request TGT in NEEDED_PREAUTH:host/<hostname> - ISSUE dialogs.
No errors and 'admin' is not encountered anywhere.
I'm having a concern that older machines could have been enrolled (ipa-client) with admin user. Could you suggest where i can check this setting on the client machines and modify if needed?
When machine is enrolled as admin, there is no place those admin credentials are stored anywhere. So that shouldn't be an issue.
However, if admin account is still locked out, you have two sources for possible lockouts: - KDC locking out for invalid TGTs - LDAP servers locking out for invalid LDAP BIND requests.
As you are saying it is not the former, may be it is the latter?
You can use
egrep '(BIND.*dn="|RESULT.*dn="|RESULT err=49)' /var/log/dirsrv/slapd-$INSTANCE/access
to pull out all authentication requests, successful or not, from LDAP server access log. For successful requests 'RESULT ' entry would have 'dn="some-dn"' while for unsuccessful ones BIND entries will have actual DN value. Each entry has 'conn=XYZ' property which show an id of a connection performed by a client and a first line with that conn=XYZ id would also have IP address of the client.
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
hedrick＠rutgers.edu -
Jochen Hein -
skrawczenko＠gmail.com