[Freeipa-users] Re: Reverse lookup Issue

[Kathy Zhu via FreeIPA-users]

Hi Rob,

Thank you for your reply.

I looked it up using both "nslookup" and "host" commands.

Adding idnsname=90.91 filter did not get me wanted results:

# ldapsearch -Y GSSAPI -b
idnsname=0.10.inaddr.arpa.,cn=dns,dc=example,dc=com idnsname=90.91

SASL/GSSAPI authentication started

SASL username: ad...@example.com

SASL SSF: 256

SASL data security layer installed.

# extended LDIF

#

# LDAPv3

# base  with scope
subtree

# filter: idnsname=90.91

# requesting: ALL

#


# search result

search: 4

result: 32 No such object

matchedDN: cn=dns,dc=example,dc=com


# numResponses: 1

#


I do not know the history of using xxx.xxx format reverse zones
instead of discrete
zones, I will suggest the team use discrete zones instead.

For my learning, I wish someone could explain why xxx.xxx format reverse
zones do not work.

Many thanks!

Kathy.

On Tue, Dec 14, 2021 at 12:20 PM Rob Crittenden  wrote:

> Kathy Zhu via FreeIPA-users wrote:
> > Hi List,
> >
> > I created a PTR record "90.91" in "0.10.inaddr.arpa." zone via GUI, then
> > found:
> >
> > 1, I can see the record via GUI
> > 2, When I looked it up on the command line, I got "not found:
> 3(NXDOMAIN)".
>
> How did you look?
>
> > 3, Its dn is not in "ldapsearch -Y GSSAPI -b
> > idnsname=0.10.inaddr.arpa.,cn=dns,dc=example,dc=com" output.
> >
>
> You can add the target idnsname=90.91, e.g.
>
> ldapsearch -Y GSSAPI -b
> idnsname=0.10.inaddr.arpa.,cn=dns,dc=example,dc=com idnsname=90.91
>
> > Above 3 explained why the record could not be resolved. However, why
> > does this happen? I can see the record in GUI, where is this record?
>
> I'm not a DNS expert by far, but this format looks a bit off. I tend to
> be simplistic and have actual zones for each reverse, so I'd have
> created 91.0.10.inaddr.arpa. and added 90 to it.
>
> I was able to duplicate what you see though using the ##.## format.
>
> So I don't know if what you're doing is wrong or if it's something in
> bind-dyndb-ldap, but having discrete zones is a workaround.
>
> rob
>
> > I created more PTR records for testing, they are all the same way - can
> > be seen in GUI, but not resolvable and not in ldapsearch output.
> >
> > Any idea for me to troubleshoot this?
> >
> > Many thanks.
> >
> > Kathy
> >
> >
> >
> >
> > ___
> > 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:
> 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.fedorahosted.org
> > Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
> >
>
>
___
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: 
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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: Users not know for a while in clients of IPA with AD trust

[tizo via FreeIPA-users]

Thanks very much John. I will try it.

On Tue, Dec 14, 2021 at 12:41 PM John Desantis 
wrote:

> Hello,
>
> Do your AD users in question belong to any IPA groups?
>
> Your symptoms are very similar to the following post:
>
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/VHTB3GR65L77SS7CS5H4GWHRMBIKQWXP/
>
> In a nutshell, AD users would only be seen on clients after multiple
> failed lookups for the cache lifetime.  The solution for us was to
> make sure that all permitted AD users belonged to an IPA external
> group that was then mapped into an IPA POSIX group.  I suppose you
> could adjust the cache lifetime on the client vs. our method, but
> you'd still run into the issue of expired entries eventually, which
> still wouldn't fix the issue.
>
> HTH,
> John DeSantis
>
> Il giorno mar 14 dic 2021 alle ore 10:07 tizo via FreeIPA-users
>  ha scritto:
> >
> > Anyone please?. I don't really know how to fix this. Thanks.
> >
> > On Thu, Dec 9, 2021 at 11:20 AM tizo  wrote:
> >>
> >> The scenario is an IPA with an AD trust. The users belong to AD. IPA is
> a Rocky Linux 8, and AD is a Samba 4.14.10 over Rocky Linux 8 too.
> >>
> >> We have a couple of IPA host clients to test. One is another Rocky
> Linux 8, and the other is an Ubuntu 20.04. Everything works fine: AD users
> can login into the clients. The only problem is, after some time of
> inactivity on the clients (not sure how much time), AD users cannot login
> anymore, but just for a while (some seconds, or a minute). In that period,
> executing an "id user" with an AD user in the client, gives me nothing.
> >>
> >> In Rocky Linux client, it seems that everything start to works again
> after SSSD Kerberos Cache Manager is started (which is done automatically),
> as can be seen in the following log from journalctl:
> >>
> >> Dec 07 12:52:08 rockyprueba.xx.xx sshd[12054]: Invalid user usupru2
> from 10.X.X.X port 56778
> >> Dec 07 12:52:09 rockyprueba.xx.xx sshd[12054]: Postponed
> keyboard-interactive for invalid user usupru2 from 10.X.X.X port 56778 ssh2
> [preauth]
> >> Dec 07 12:52:12 rockyprueba.xx.xx sshd[12056]: pam_unix(sshd:auth):
> check pass; user unknown
> >> Dec 07 12:52:12 rockyprueba.xx.xx sshd[12056]: pam_unix(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X
> >> Dec 07 12:52:14 rockyprueba.xx.xx sshd[12054]: error: PAM:
> Authentication failure for illegal user usupru2 from 10.X.X.X
> >> Dec 07 12:52:14 rockyprueba.xx.xx sshd[12054]: Failed
> keyboard-interactive/pam for invalid user usupru2 from 10.X.X.X port 56778
> ssh2
> >> Dec 07 12:52:14 rockyprueba.xx.xx sshd[12054]: Postponed
> keyboard-interactive for invalid user usupru2 from 10.X.X.X port 56778 ssh2
> [preauth]
> >> Dec 07 12:52:19 rockyprueba.xx.xx sshd[12057]: pam_unix(sshd:auth):
> check pass; user unknown
> >> Dec 07 12:52:19 rockyprueba.xx.xx sshd[12057]: pam_unix(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X
> >> Dec 07 12:52:21 rockyprueba.xx.xx sshd[12054]: error: PAM:
> Authentication failure for illegal user usupru2 from 10.X.X.X
> >> Dec 07 12:52:21 rockyprueba.xx.xx sshd[12054]: Failed
> keyboard-interactive/pam for invalid user usupru2 from 10.X.X.X port 56778
> ssh2
> >> Dec 07 12:52:21 rockyprueba.xx.xx sshd[12054]: Postponed
> keyboard-interactive for invalid user usupru2 from 10.X.X.X port 56778 ssh2
> [preauth]
> >> Dec 07 12:52:32 rockyprueba.xx.xx sshd[12058]: pam_unix(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=10.X.X.X  user=usupru2
> >> Dec 07 12:52:32 rockyprueba.xx.xx krb5_child[12061]: Preauthentication
> failed
> >> Dec 07 12:52:32 rockyprueba.xx.xx krb5_child[12061]: Preauthentication
> failed
> >> Dec 07 12:52:32 rockyprueba.xx.xx sshd[12058]: pam_sss(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X
> user=usupru2
> >> Dec 07 12:52:32 rockyprueba.xx.xx sshd[12058]: pam_sss(sshd:auth):
> received for user usupru2: 7 (Authentication failure)
> >> Dec 07 12:52:34 rockyprueba.xx.xx sshd[12054]: error: PAM:
> Authentication failure for illegal user usupru2 from 10.X.X.X
> >> Dec 07 12:52:34 rockyprueba.xx.xx sshd[12054]: Failed
> keyboard-interactive/pam for invalid user usupru2 from 10.X.X.X port 56778
> ssh2
> >> Dec 07 12:52:36 rockyprueba.xx.xx sshd[12054]: Connection closed by
> invalid user usupru2 10.X.X.X port 56778 [preauth]
> >> Dec 07 12:52:40 rockyprueba.xx.xx systemd[1]: Starting SSSD Kerberos
> Cache Manager...
> >> Dec 07 12:52:40 rockyprueba.xx.xx systemd[1]: Started SSSD Kerberos
> Cache Manager.
> >> Dec 07 12:52:40 rockyprueba.xx.xx sssd_kcm[12068]: Starting up
> >> Dec 07 12:52:40 rockyprueba.xx.xx sshd[12064]: pam_sss(sshd:auth):
> authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X
> user=usupru2
> >> Dec 07 12:52:41 rockyprueba.xx.xx sshd[12062]: Accepted
> keyboard-interactive/pam for usupru2 from 

[Freeipa-users] Re: Reverse lookup Issue

[Rob Crittenden via FreeIPA-users]

Kathy Zhu via FreeIPA-users wrote:
> Hi List, 
> 
> I created a PTR record "90.91" in "0.10.inaddr.arpa." zone via GUI, then
> found: 
> 
> 1, I can see the record via GUI 
> 2, When I looked it up on the command line, I got "not found: 3(NXDOMAIN)". 

How did you look?

> 3, Its dn is not in "ldapsearch -Y GSSAPI -b 
> idnsname=0.10.inaddr.arpa.,cn=dns,dc=example,dc=com" output. 
> 

You can add the target idnsname=90.91, e.g.

ldapsearch -Y GSSAPI -b
idnsname=0.10.inaddr.arpa.,cn=dns,dc=example,dc=com idnsname=90.91

> Above 3 explained why the record could not be resolved. However, why
> does this happen? I can see the record in GUI, where is this record? 

I'm not a DNS expert by far, but this format looks a bit off. I tend to
be simplistic and have actual zones for each reverse, so I'd have
created 91.0.10.inaddr.arpa. and added 90 to it.

I was able to duplicate what you see though using the ##.## format.

So I don't know if what you're doing is wrong or if it's something in
bind-dyndb-ldap, but having discrete zones is a workaround.

rob

> I created more PTR records for testing, they are all the same way - can
> be seen in GUI, but not resolvable and not in ldapsearch output. 
> 
> Any idea for me to troubleshoot this?
> 
> Many thanks. 
> 
> Kathy 
> 
> 
> 
> 
> ___
> 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: 
> 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.fedorahosted.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
> 
___
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: 
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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] master/replica dnssec 'sending notifies' back forever??

[Harry G. Coin via FreeIPA-users]

In a master/replica freeipa setup with DNSSEC -- is it normal the 
"sending notifies" happens forever?


It would appear the master sends a notify for a zone, the replica gets 
it, sees an updated SOA, updates itself, sends a notify to the master, 
which sees a higher SOA, updates itself, sends a notify to the replica 
.. again and again forever, and once for each zone.


How can this be avoided?

Thanks

Harry Coin

___
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: 
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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Reverse lookup Issue

[Kathy Zhu via FreeIPA-users]

Hi List,

I created a PTR record "90.91" in "0.10.inaddr.arpa." zone via GUI, then
found:

1, I can see the record via GUI
2, When I looked it up on the command line, I got "not found: 3(NXDOMAIN)".
3, Its dn is not in "ldapsearch -Y GSSAPI -b
idnsname=0.10.inaddr.arpa.,cn=dns,dc=example,dc=com"
output.

Above 3 explained why the record could not be resolved. However, why does
this happen? I can see the record in GUI, where is this record?

I created more PTR records for testing, they are all the same way - can be
seen in GUI, but not resolvable and not in ldapsearch output.

Any idea for me to troubleshoot this?

Many thanks.

Kathy
___
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: 
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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: how to get xrdp to work with ipa users

[Rob Verduijn via FreeIPA-users]

Hi all,

Sorry for the reply to an ancient post.

But I thought I share how I finally managed to get xrdp to play nice with
freeipa.

The solution was rather simple.
When in ipa allow_all policy is disabled.
Add xrdep-sesman to the hbac-services then add the service to the
hbac-policy that allows desktop access.

after that you can login with an ipa user via xrdp
this even works for ad-domain users when you have configured a trust and
mapped all the required groups.

Rob
___
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: 
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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Replication broken after upgrade

[Serge Krawczenko via FreeIPA-users]

Hello there,

Something went wrong after recent yum update (CentOS 7)
The current version is 4.6.8-5.el7.centos.9

I have two FreeIPA replicas  and one Active Directory agreement (winsync)

Here what i'm getting from cn=replicacn=mapping tree,cn=config

nsds5replicaLastUpdateStart: 1970010100Z
nsds5replicaLastUpdateEnd: 1970010100Z

nsds5replicaLastInitStart: 1970010100Z
nsds5replicaLastInitEnd: 1970010100Z

This is  for both agreements, however winsync is still alive somehow.
Replication to the second FreeIPA node no longer works, and
when trying to re-initialize, here's what i'm getting:

ipa-replica-manage re-initialize --from= --verbose

Traceback (most recent call last):
  File "/sbin/ipa-replica-manage", line 1624, in 
main(options, args)
  File "/sbin/ipa-replica-manage", line 1567, in main
options.nolookup)
  File "/sbin/ipa-replica-manage", line 1220, in re_initialize
repl.initialize_replication(agreement.dn, repl.conn)
  File "/usr/lib/python2.7/site-packages/ipaserver/install/replication.py",
line 1358, in initialize_replication
conn.modify_s(dn, mod)
  File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 792,
in modify_s
return self.conn.modify_s(dn, modlist)
  File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 357,
in modify_s
return self.result(msgid,all=1,timeout=self.timeout)
  File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 458,
in result
resp_type, resp_data, resp_msgid = self.result2(msgid,all,timeout)
  File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 462,
in result2
resp_type, resp_data, resp_msgid, resp_ctrls =
self.result3(msgid,all,timeout)
  File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 469,
in result3
resp_ctrl_classes=resp_ctrl_classes
  File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 476,
in result4
ldap_result =
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
  File "/usr/lib64/python2.7/site-packages/ldap/ldapobject.py", line 99, in
_ldap_call
result = func(*args,**kwargs)
TYPE_OR_VALUE_EXISTS: {'desc': 'Type or value exists'}
Unexpected error: {'desc': 'Type or value exists'}


I feel that the exception is related to time set to 1970010100Z or some
other cn=config parameter.

Another suspicious thing which may be related is:

Running on node0:

ipa-replica-manage list -v 

Failed to get data from 'node1': Insufficient access: SASL(-1): generic
failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide
more information (Server krbtgt/ not found in
Kerberos database)

Any advice on how to fix without rebuilding everything ?

Thank you
___
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: 
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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: Clear sssd cache

[Sumit Bose via FreeIPA-users]

Am Tue, Dec 14, 2021 at 01:05:52PM +0100 schrieb Ronald Wimmer via 
FreeIPA-users:
> On 10.12.21 09:50, Florence Blanc-Renaud wrote:
> > Hi,
> > 
> > You can have a look at
> > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_authentication_and_authorization_in_rhel/index#con_data-flow-when-retrieving-idm-user-information-with-sssd_assembly_troubleshooting-authentication-with-sssd-in-idm.
> > The diagram shows the "memcache" and "LDB cache".
> > 
> > I hope I'm not mixing both but I believe the "memcache" corresponds to
> > /var/lib/sss/mc/* while "LDB cache" to /var/lib/sss/db/. The commands
> > sss_cache and sssctl cache-expire *invalidate* the records in the cache,
> > which I understand as "mark them as if they were expired", not as "delete
> > them". From sss_cache man page: "Invalidated records are forced to be
> > reloaded from server as soon as related SSSD backend is online."
> 
> Thanks for the clarification. This makes sense.
> 
> Currently, we have /var/lib/sss/db in RAM to gain a little performance:
> #Performancetuning for SSSD/IPA
> tmpfs /var/lib/sss/db/tmpfs   size=1024M,mode=0700
> 
> Wouldn't it make sense to put /var/lib/sss/mc in RAM too?

Hi,

the memcache files will be opened as memory mapped files, so they are
already in RAM.

HTH

bye,
Sumit

> 
> Cheers,
> Ronald
> ___
> 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: 
> 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.fedorahosted.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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: 
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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: Users not know for a while in clients of IPA with AD trust

[John Desantis via FreeIPA-users]

Hello,

Do your AD users in question belong to any IPA groups?

Your symptoms are very similar to the following post:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/VHTB3GR65L77SS7CS5H4GWHRMBIKQWXP/

In a nutshell, AD users would only be seen on clients after multiple
failed lookups for the cache lifetime.  The solution for us was to
make sure that all permitted AD users belonged to an IPA external
group that was then mapped into an IPA POSIX group.  I suppose you
could adjust the cache lifetime on the client vs. our method, but
you'd still run into the issue of expired entries eventually, which
still wouldn't fix the issue.

HTH,
John DeSantis

Il giorno mar 14 dic 2021 alle ore 10:07 tizo via FreeIPA-users
 ha scritto:
>
> Anyone please?. I don't really know how to fix this. Thanks.
>
> On Thu, Dec 9, 2021 at 11:20 AM tizo  wrote:
>>
>> The scenario is an IPA with an AD trust. The users belong to AD. IPA is a 
>> Rocky Linux 8, and AD is a Samba 4.14.10 over Rocky Linux 8 too.
>>
>> We have a couple of IPA host clients to test. One is another Rocky Linux 8, 
>> and the other is an Ubuntu 20.04. Everything works fine: AD users can login 
>> into the clients. The only problem is, after some time of inactivity on the 
>> clients (not sure how much time), AD users cannot login anymore, but just 
>> for a while (some seconds, or a minute). In that period, executing an "id 
>> user" with an AD user in the client, gives me nothing.
>>
>> In Rocky Linux client, it seems that everything start to works again after 
>> SSSD Kerberos Cache Manager is started (which is done automatically), as can 
>> be seen in the following log from journalctl:
>>
>> Dec 07 12:52:08 rockyprueba.xx.xx sshd[12054]: Invalid user usupru2 from 
>> 10.X.X.X port 56778
>> Dec 07 12:52:09 rockyprueba.xx.xx sshd[12054]: Postponed 
>> keyboard-interactive for invalid user usupru2 from 10.X.X.X port 56778 ssh2 
>> [preauth]
>> Dec 07 12:52:12 rockyprueba.xx.xx sshd[12056]: pam_unix(sshd:auth): check 
>> pass; user unknown
>> Dec 07 12:52:12 rockyprueba.xx.xx sshd[12056]: pam_unix(sshd:auth): 
>> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X
>> Dec 07 12:52:14 rockyprueba.xx.xx sshd[12054]: error: PAM: Authentication 
>> failure for illegal user usupru2 from 10.X.X.X
>> Dec 07 12:52:14 rockyprueba.xx.xx sshd[12054]: Failed 
>> keyboard-interactive/pam for invalid user usupru2 from 10.X.X.X port 56778 
>> ssh2
>> Dec 07 12:52:14 rockyprueba.xx.xx sshd[12054]: Postponed 
>> keyboard-interactive for invalid user usupru2 from 10.X.X.X port 56778 ssh2 
>> [preauth]
>> Dec 07 12:52:19 rockyprueba.xx.xx sshd[12057]: pam_unix(sshd:auth): check 
>> pass; user unknown
>> Dec 07 12:52:19 rockyprueba.xx.xx sshd[12057]: pam_unix(sshd:auth): 
>> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X
>> Dec 07 12:52:21 rockyprueba.xx.xx sshd[12054]: error: PAM: Authentication 
>> failure for illegal user usupru2 from 10.X.X.X
>> Dec 07 12:52:21 rockyprueba.xx.xx sshd[12054]: Failed 
>> keyboard-interactive/pam for invalid user usupru2 from 10.X.X.X port 56778 
>> ssh2
>> Dec 07 12:52:21 rockyprueba.xx.xx sshd[12054]: Postponed 
>> keyboard-interactive for invalid user usupru2 from 10.X.X.X port 56778 ssh2 
>> [preauth]
>> Dec 07 12:52:32 rockyprueba.xx.xx sshd[12058]: pam_unix(sshd:auth): 
>> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X  
>> user=usupru2
>> Dec 07 12:52:32 rockyprueba.xx.xx krb5_child[12061]: Preauthentication failed
>> Dec 07 12:52:32 rockyprueba.xx.xx krb5_child[12061]: Preauthentication failed
>> Dec 07 12:52:32 rockyprueba.xx.xx sshd[12058]: pam_sss(sshd:auth): 
>> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X 
>> user=usupru2
>> Dec 07 12:52:32 rockyprueba.xx.xx sshd[12058]: pam_sss(sshd:auth): received 
>> for user usupru2: 7 (Authentication failure)
>> Dec 07 12:52:34 rockyprueba.xx.xx sshd[12054]: error: PAM: Authentication 
>> failure for illegal user usupru2 from 10.X.X.X
>> Dec 07 12:52:34 rockyprueba.xx.xx sshd[12054]: Failed 
>> keyboard-interactive/pam for invalid user usupru2 from 10.X.X.X port 56778 
>> ssh2
>> Dec 07 12:52:36 rockyprueba.xx.xx sshd[12054]: Connection closed by invalid 
>> user usupru2 10.X.X.X port 56778 [preauth]
>> Dec 07 12:52:40 rockyprueba.xx.xx systemd[1]: Starting SSSD Kerberos Cache 
>> Manager...
>> Dec 07 12:52:40 rockyprueba.xx.xx systemd[1]: Started SSSD Kerberos Cache 
>> Manager.
>> Dec 07 12:52:40 rockyprueba.xx.xx sssd_kcm[12068]: Starting up
>> Dec 07 12:52:40 rockyprueba.xx.xx sshd[12064]: pam_sss(sshd:auth): 
>> authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X 
>> user=usupru2
>> Dec 07 12:52:41 rockyprueba.xx.xx sshd[12062]: Accepted 
>> keyboard-interactive/pam for usupru2 from 10.X.X.X port 56786 ssh2
>>
>> Whereas in Ubuntu I can see the following related lines in the auth log:
>>
>> Dec  9 10:15:52 

[Freeipa-users] Re: Users not know for a while in clients of IPA with AD trust

[tizo via FreeIPA-users]

Anyone please?. I don't really know how to fix this. Thanks.

On Thu, Dec 9, 2021 at 11:20 AM tizo  wrote:

> The scenario is an IPA with an AD trust. The users belong to AD. IPA is a
> Rocky Linux 8, and AD is a Samba 4.14.10 over Rocky Linux 8 too.
>
> We have a couple of IPA host clients to test. One is another Rocky Linux
> 8, and the other is an Ubuntu 20.04. Everything works fine: AD users can
> login into the clients. The only problem is, after some time of inactivity
> on the clients (not sure how much time), AD users cannot login anymore, but
> just for a while (some seconds, or a minute). In that period, executing an
> "id user" with an AD user in the client, gives me nothing.
>
> In Rocky Linux client, it seems that everything start to works again after
> SSSD Kerberos Cache Manager is started (which is done automatically), as
> can be seen in the following log from journalctl:
>
> Dec 07 12:52:08 rockyprueba.xx.xx sshd[12054]: Invalid user usupru2 from
> 10.X.X.X port 56778
> Dec 07 12:52:09 rockyprueba.xx.xx sshd[12054]: Postponed
> keyboard-interactive for invalid user usupru2 from 10.X.X.X port 56778 ssh2
> [preauth]
> Dec 07 12:52:12 rockyprueba.xx.xx sshd[12056]: pam_unix(sshd:auth): check
> pass; user unknown
> Dec 07 12:52:12 rockyprueba.xx.xx sshd[12056]: pam_unix(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X
> Dec 07 12:52:14 rockyprueba.xx.xx sshd[12054]: error: PAM: Authentication
> failure for illegal user usupru2 from 10.X.X.X
> Dec 07 12:52:14 rockyprueba.xx.xx sshd[12054]: Failed
> keyboard-interactive/pam for invalid user usupru2 from 10.X.X.X port 56778
> ssh2
> Dec 07 12:52:14 rockyprueba.xx.xx sshd[12054]: Postponed
> keyboard-interactive for invalid user usupru2 from 10.X.X.X port 56778 ssh2
> [preauth]
> Dec 07 12:52:19 rockyprueba.xx.xx sshd[12057]: pam_unix(sshd:auth): check
> pass; user unknown
> Dec 07 12:52:19 rockyprueba.xx.xx sshd[12057]: pam_unix(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X
> Dec 07 12:52:21 rockyprueba.xx.xx sshd[12054]: error: PAM: Authentication
> failure for illegal user usupru2 from 10.X.X.X
> Dec 07 12:52:21 rockyprueba.xx.xx sshd[12054]: Failed
> keyboard-interactive/pam for invalid user usupru2 from 10.X.X.X port 56778
> ssh2
> Dec 07 12:52:21 rockyprueba.xx.xx sshd[12054]: Postponed
> keyboard-interactive for invalid user usupru2 from 10.X.X.X port 56778 ssh2
> [preauth]
> Dec 07 12:52:32 rockyprueba.xx.xx sshd[12058]: pam_unix(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X
>  user=usupru2
> Dec 07 12:52:32 rockyprueba.xx.xx krb5_child[12061]: Preauthentication
> failed
> Dec 07 12:52:32 rockyprueba.xx.xx krb5_child[12061]: Preauthentication
> failed
> Dec 07 12:52:32 rockyprueba.xx.xx sshd[12058]: pam_sss(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X
> user=usupru2
> Dec 07 12:52:32 rockyprueba.xx.xx sshd[12058]: pam_sss(sshd:auth):
> received for user usupru2: 7 (Authentication failure)
> Dec 07 12:52:34 rockyprueba.xx.xx sshd[12054]: error: PAM: Authentication
> failure for illegal user usupru2 from 10.X.X.X
> Dec 07 12:52:34 rockyprueba.xx.xx sshd[12054]: Failed
> keyboard-interactive/pam for invalid user usupru2 from 10.X.X.X port 56778
> ssh2
> Dec 07 12:52:36 rockyprueba.xx.xx sshd[12054]: Connection closed by
> invalid user usupru2 10.X.X.X port 56778 [preauth]
> Dec 07 12:52:40 rockyprueba.xx.xx systemd[1]: Starting SSSD Kerberos Cache
> Manager...
> Dec 07 12:52:40 rockyprueba.xx.xx systemd[1]: Started SSSD Kerberos Cache
> Manager.
> Dec 07 12:52:40 rockyprueba.xx.xx sssd_kcm[12068]: Starting up
> Dec 07 12:52:40 rockyprueba.xx.xx sshd[12064]: pam_sss(sshd:auth):
> authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X
> user=usupru2
> Dec 07 12:52:41 rockyprueba.xx.xx sshd[12062]: Accepted
> keyboard-interactive/pam for usupru2 from 10.X.X.X port 56786 ssh2
>
> Whereas in Ubuntu I can see the following related lines in the auth log:
>
> Dec  9 10:15:52 ubuntuprueba sshd[66229]: Invalid user usupru2 from
> 10.X.X.X port 43534
> Dec  9 10:15:57 ubuntuprueba sshd[66229]: Postponed keyboard-interactive
> for invalid user usupru2 from 10.X.X.X port 43534 ssh2 [preauth]
> Dec  9 10:16:12 ubuntuprueba sshd[66231]: pam_unix(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X
>  user=usupru2
> Dec  9 10:16:12 ubuntuprueba sshd[66231]: pam_sss(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.X.X.X
> user=usupru2
> Dec  9 10:16:12 ubuntuprueba sshd[66231]: pam_sss(sshd:auth): received for
> user usupru2: 17 (Failure setting user credentials)
> Dec  9 10:16:14 ubuntuprueba sshd[66229]: error: PAM: Authentication
> failure for illegal user usupru2 from 10.X.X.X
> Dec  9 10:16:14 ubuntuprueba sshd[66229]: Failed keyboard-interactive/pam
> for invalid user usupru2 from 10.X.X.X 

[Freeipa-users] Re: Clear sssd cache

[Ronald Wimmer via FreeIPA-users]

On 10.12.21 09:50, Florence Blanc-Renaud wrote:

Hi,

You can have a look at
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html-single/configuring_authentication_and_authorization_in_rhel/index#con_data-flow-when-retrieving-idm-user-information-with-sssd_assembly_troubleshooting-authentication-with-sssd-in-idm.
The diagram shows the "memcache" and "LDB cache".

I hope I'm not mixing both but I believe the "memcache" corresponds to
/var/lib/sss/mc/* while "LDB cache" to /var/lib/sss/db/. The commands
sss_cache and sssctl cache-expire *invalidate* the records in the cache,
which I understand as "mark them as if they were expired", not as "delete
them". From sss_cache man page: "Invalidated records are forced to be
reloaded from server as soon as related SSSD backend is online."


Thanks for the clarification. This makes sense.

Currently, we have /var/lib/sss/db in RAM to gain a little performance:
#Performancetuning for SSSD/IPA
tmpfs   /var/lib/sss/db/tmpfs   size=1024M,mode=0700

Wouldn't it make sense to put /var/lib/sss/mc in RAM too?

Cheers,
Ronald
___
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: 
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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] trustdomain-disable

[Ronald Wimmer via FreeIPA-users]

Hi,

In our setup we have a forest root domain. Let's call it mydomain.at 
with two subdomains domainone.mydomain.at and domaintwo.mydomain.at. 
Users are only located in domainone.mydomain.at. So we disabled 
domaintwo.mydomain.at with trustdomain-disable.


Is there any way to prevent the forest root domain mydomain.at from 
beeing searched as we do not have any users there in order to gain 
another little bit of performance?


Cheers,
Ronald
___
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: 
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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: OTP behaviour on Debian

[Sam Morris via FreeIPA-users]

On Tue, 2021-12-14 at 10:23 +0100, Sumit Bose wrote:
> Am Mon, Dec 13, 2021 at 06:14:13PM - schrieb Sam Morris via FreeIPA-users:
> 
> > 
> > I've filed https://bugs.debian.org/1001644 to discuss whether pam_sss can 
> > be moved before pam_unix in the Debian packaging.
> 
> Btw, in RHEL and Fedora we use authselect
> (https://github.com/authselect/authselect) to flexible manage the
> system's PAM configuration. Maybe this is something Debian would like to
> adopt as well.

As a user that would sure be nice. Debian has pam-auth-update which
does the same thing but doesn't really have any user-configurable
knobs. But I don't plan on carrying the torch to get pam-auth-update
adopted... :)

Regardless, I found that bumping the priority of the sss pam-auth-
update config file to a value greater than that of the unix config file
causes pam-auth-update to do the right thing and we get:

   # here are the per-package modules (the "Primary" block)
   auth [success=2 default=ignore]  pam_sss.so forward_pass
   auth [success=1 default=ignore]  pam_unix.so nullok try_first_pass
   # here's the fallback if no module succeeds

Which appears to work fine for both local and directory users on my
system.

However, I note that on Red Hat, pam_localuser is used on to ensure
that local users are handled by pam_unix, and non-local users are only
handled by pam_sss. Is there any benefit to doing this, or is a config
like what I pasted above OK as well?

-- 
Sam Morris 
PGP: rsa4096/CAAA AA1A CA69 A83A 892B  1855 D20B 4202 5CDA 27B9

___
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: 
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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: Performance Problem and IPA Server startup

[Georg Seyerl via FreeIPA-users]

Hi John,
thank you for those settings. With the information above we were able to reduce 
the login time significantly.
Especially the trustdomain hint of yours is brilliant.
We reduced the login time to consistent 3.5s.
Best,
Georg
___
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: 
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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: OTP behaviour on Debian

[Sumit Bose via FreeIPA-users]

Am Mon, Dec 13, 2021 at 06:14:13PM - schrieb Sam Morris via FreeIPA-users:
> You're absolutely right. On Debian in /etc/pam.d/common-auth we have:
> 
> # here are the per-package modules (the "Primary" block)
> auth[success=2 default=ignore]  pam_unix.so nullok
> auth[success=1 default=ignore]  pam_sss.so use_first_pass
> # here's the fallback if no module succeeds
> authrequisite   pam_deny.so
> # prime the stack with a positive return value if there isn't one already;
> # this avoids us returning an error just because nothing sets a success code
> # since the modules above will each just jump around
> authrequiredpam_permit.so
> # and here are more per-package modules (the "Additional" block)
> authoptionalpam_cap.so 
> # end of pam-auth-update config
> 
> A quick hack that removes pam_unix.so and removes the use_first_pass line 
> from pam_sssd.so results in the OTP prompts being produced by pam_sssd. 
> Thanks!

Hi,

glad I could help.

> 
> I've filed https://bugs.debian.org/1001644 to discuss whether pam_sss can be 
> moved before pam_unix in the Debian packaging.

Btw, in RHEL and Fedora we use authselect
(https://github.com/authselect/authselect) to flexible manage the
system's PAM configuration. Maybe this is something Debian would like to
adopt as well.

bye,
Sumit

> 
> --
> Sam Morris 
> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9
> ___
> 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: 
> 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.fedorahosted.org
> Do not reply to spam on the list, report it: 
> https://pagure.io/fedora-infrastructure
___
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: 
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.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure