Today I was not able to log in with an AD user to an IPA client within a test setup. IPA users worked fine.
DNS is managed externally. I figured out that the DNS-Record of that particular IPA client has not been created correctly. After having corrected the DNS entry and having dropped the SSSD cache on that client I could login with my AD user.
Do you have an explanation for that or was it just a coincidence?
Cheers, Ronald
On Wed, Nov 06, 2019 at 12:20:21AM +0100, Ronald Wimmer via FreeIPA-users wrote:
Today I was not able to log in with an AD user to an IPA client within a test setup. IPA users worked fine.
DNS is managed externally. I figured out that the DNS-Record of that particular IPA client has not been created correctly. After having corrected the DNS entry and having dropped the SSSD cache on that client I could login with my AD user.
Do you have an explanation for that or was it just a coincidence?
Hi,
it depends on what 'not able to log in' means. If it e.g. means that you tried to log in from a Windows clients with putty or similar then with a broken DNS record putty will not be able to find or connect to the expected IPA client.
bye, Sumit
Cheers, Ronald _______________________________________________ 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://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.fedorahoste...
On 06.11.19 08:08, Sumit Bose via FreeIPA-users wrote:
On Wed, Nov 06, 2019 at 12:20:21AM +0100, Ronald Wimmer via FreeIPA-users wrote:
Today I was not able to log in with an AD user to an IPA client within a test setup. IPA users worked fine.
DNS is managed externally. I figured out that the DNS-Record of that particular IPA client has not been created correctly. After having corrected the DNS entry and having dropped the SSSD cache on that client I could login with my AD user.
Do you have an explanation for that or was it just a coincidence?
Hi,
it depends on what 'not able to log in' means. If it e.g. means that you tried to log in from a Windows clients with putty or similar then with a broken DNS record putty will not be able to find or connect to the expected IPA client.
I entered the credentials of my AD user and was prompted for the password several times.
Cheers, Ronald
The only log entries that appear when a different user tries it do appear in /var/log/secure:
Nov 6 10:33:19 ws102317180 sshd[24003]: Invalid user an_ad_user@bau.mydomain.at from 10.16.11.218 port 60646 Nov 6 10:33:19 ws102317180 sshd[24003]: input_userauth_request: invalid user an_ad_user@bau.mydomain.at [preauth] Nov 6 10:33:19 ws102317180 sshd[24003]: Postponed keyboard-interactive for invalid user an_ad_user@bau.mydomain.at from 10.16.11.218 port 60646 ssh2 [preauth] Nov 6 10:33:26 ws102317180 sshd[24005]: pam_unix(sshd:auth): check pass; user unknown Nov 6 10:33:26 ws102317180 sshd[24005]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=somehost.bau.mydomain.at Nov 6 10:33:28 ws102317180 sshd[24003]: error: PAM: User not known to the underlying authentication module for illegal user an_ad_user@bau.mydomain.at from somehost.bau.mydomain.at Nov 6 10:33:28 ws102317180 sshd[24003]: Failed keyboard-interactive/pam for invalid user an_ad_user@bau.mydomain.at from 10.16.11.218 port 60646 ssh2 Nov 6 10:33:28 ws102317180 sshd[24003]: Postponed keyboard-interactive for invalid user an_ad_user@bau.mydomain.at from 10.16.11.218 port 60646 ssh2 [preauth] Nov 6 10:33:38 ws102317180 sshd[24006]: pam_unix(sshd:auth): check pass; user unknown Nov 6 10:33:38 ws102317180 sshd[24006]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=somehost.bau.mydomain.at Nov 6 10:33:39 ws102317180 sshd[24003]: error: PAM: User not known to the underlying authentication module for illegal user an_ad_user@bau.mydomain.at from as03184.bau.mydomain.at Nov 6 10:33:39 ws102317180 sshd[24003]: Failed keyboard-interactive/pam for invalid user an_ad_user@bau.mydomain.at from 10.16.11.218 port 60646 ssh2 Nov 6 10:33:39 ws102317180 sshd[24003]: Postponed keyboard-interactive for invalid user an_ad_user@bau.mydomain.at from 10.16.11.218 port 60646 ssh2 [preauth]
On one of the IPA servers themselves a
getent passwd myaduser@bau.mydomain.at
is working. On the system where I cannot login with this user I do not get a result.
What do I have to look for in which sssd log file in order to find out what the problem is?
Cheers, Ronald
Simply increasing the krb5_auth_timeout in the client's sssd.conf did the trick. Thanks for the good troubleshooting guide at https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
Cheers, Ronald
It seems that this was a coincidence... sometimes AD users are found but most of the time they are not:
[root@ipaclient sssd]# id usera@bau.mydomain.at id: usera@bau.mydomain.at: No such user [root@ipaclient sssd]# id userb@bau.mydomain.at id: userb@bau.mydomain.at: No such user
Where do I have to take a closer look?
Cheers, Ronald
On Fri, Nov 08, 2019 at 10:04:41AM +0100, Ronald Wimmer via FreeIPA-users wrote:
It seems that this was a coincidence... sometimes AD users are found but most of the time they are not:
[root@ipaclient sssd]# id usera@bau.mydomain.at id: usera@bau.mydomain.at: No such user [root@ipaclient sssd]# id userb@bau.mydomain.at id: userb@bau.mydomain.at: No such user
Where do I have to take a closer look?
Hi,
please check on the IPA server. What is the output of 'id usera@bau.mydomain.at' on the IPA server when the client returns 'No such user'?
Additionally please check the SSSD logs on the IPA server if there are any issue looking up the user or any groups the user is a member of.
bye, Sumit
Cheers, Ronald _______________________________________________ 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://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.fedorahoste...
On 08.11.19 10:15, Sumit Bose via FreeIPA-users wrote:
On Fri, Nov 08, 2019 at 10:04:41AM +0100, Ronald Wimmer via FreeIPA-users wrote:
It seems that this was a coincidence... sometimes AD users are found but most of the time they are not:
[root@ipaclient sssd]# id usera@bau.mydomain.at id: usera@bau.mydomain.at: No such user [root@ipaclient sssd]# id userb@bau.mydomain.at id: userb@bau.mydomain.at: No such user
Where do I have to take a closer look?
Hi,
please check on the IPA server. What is the output of 'id usera@bau.mydomain.at' on the IPA server when the client returns 'No such user'?
There is apparently no problem on the ipa servers themselves. id usera@bau.mydomain.at did work every time I tried...
Additionally please check the SSSD logs on the IPA server if there are any issue looking up the user or any groups the user is a member of.
In order to avoid an AD group problem I created an external group with the AD users as members (instead of putting an AD group there) and mapped that group to an IPA POSIX group.
Cheers, Ronald
I think I know where to take a closer look.
I have 2 IPA servers, let's call them ipaA and ipaB. On ipaA everything works without any problems. On ipaB I cannot resolve AD users.
The "ipa trust-add" command has only been issued on ipaA. Some time ago I read about trust controllers and trust agents on https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
Are these assumptions true: - ipaA became a trust controller by issuing the "ipa trust-add" command - ipaB will have to be configured as trust agent
Cheers, Ronald
On pe, 08 marras 2019, Ronald Wimmer via FreeIPA-users wrote:
I think I know where to take a closer look.
I have 2 IPA servers, let's call them ipaA and ipaB. On ipaA everything works without any problems. On ipaB I cannot resolve AD users.
The "ipa trust-add" command has only been issued on ipaA. Some time ago I read about trust controllers and trust agents on https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
Are these assumptions true:
- ipaA became a trust controller by issuing the "ipa trust-add" command
- ipaB will have to be configured as trust agent
Correct. By running ipa-adtrust-install --add-agents on ipaA, you can add ipaB to the set of trust agents.
On 08.11.19 11:08, Alexander Bokovoy via FreeIPA-users wrote:
[...]
Are these assumptions true:
- ipaA became a trust controller by issuing the "ipa trust-add" command
- ipaB will have to be configured as trust agent
Correct. By running ipa-adtrust-install --add-agents on ipaA, you can add ipaB to the set of trust agents.
Thank you very much. Now I have a working setup.
Just two remaining questions... 1) If I wanted another server to be a trust controller I would run "ipa-adtrust-install" on that server?
2) In order to add all remaining IPA servers as a trust agent I could run "ipa-adtrust-install --add-agents" on any trust controller in my setup?
Cheers, Ronald
On pe, 08 marras 2019, Ronald Wimmer via FreeIPA-users wrote:
On 08.11.19 11:08, Alexander Bokovoy via FreeIPA-users wrote:
[...]
Are these assumptions true:
- ipaA became a trust controller by issuing the "ipa trust-add" command
- ipaB will have to be configured as trust agent
Correct. By running ipa-adtrust-install --add-agents on ipaA, you can add ipaB to the set of trust agents.
Thank you very much. Now I have a working setup.
Just two remaining questions...
If I wanted another server to be a trust controller I would run "ipa-adtrust-install" on that server?
Correct.
In order to add all remaining IPA servers as a trust agent I could run "ipa-adtrust-install --add-agents" on any trust controller in my setup?
Correct.
One catch that is not fixed yet is promotion of the compat tree configurations on trust agents. There is a need to update cn=config entries to add special attributes. We do it in ipa-adtrust-install so they are always correct on the trust controllers but since ipa-adtrust-install isn't run on trust agents themselves, no changes done to cn=config there. We need to solve this somehow, via some kind of a remote call similar how replica connectivity check is done.
sshd[24003]: error: PAM: User not known to the underlying authentication module for illegal user
I've occasionally had a similar problem.
The most recent time, it was only ssh that couldn't find the user.
'id user' worked, 'su user' worked, 'kinit user' worked.
Only 'ssh user@host' didn't work.
And then, even 'ssh user@host' worked.
I suspect, but can't prove, that it was an intermittent problem talking to the AD server.
User's credentials are cached now, so totally not able to troubleshoot further.
freeipa-users@lists.fedorahosted.org