[Freeipa-users] Re: performance tuning IPA 4.5 and SSD for large AD integration

[Alexandre Pitre via FreeIPA-users]

Hi Jakub,

I understand that cache_first=true is set in the [nss] section of
/etc/sssd/sssd.conf but what about the negative cache setting you are
referring to ? Could you please give an example ?

Looking at https://jhrozek.fedorapeople.org/sssd/1.16.2/man/sssd.conf.5.html
, there's a few settings referring to "negative cache".

Thanks
Alex
___
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://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.fedorahosted.org/message/ZTFOYQE25XZSUBZ2UIAOE5JNSFVFMNXX/

[Freeipa-users] Re: Trusted AD users can no longer authenticate via SSH

[Alexandre Pitre via FreeIPA-users]

Thanks Alexander that was it.

On Wed, Feb 14, 2018 at 6:06 AM, Alexander Bokovoy <aboko...@redhat.com>
wrote:

> On ke, 14 helmi 2018, Alexandre Pitre via FreeIPA-users wrote:
>
>> Earlier this week, users reported they could no longer ssh to freeipa
>> joined servers using their AD login. After some inverstigation, it was
>> discovered if krb5_validate was set to false in the sssd.conf, AD ssh
>> login
>> would start working again.
>>
>> One of our IPA server is showing these errors in /var/log/messages:
>>
>> Feb 13 20:53:28 ipaserver ns-slapd: [13/Feb/2018:20:53:28.823685558
>> +]
>> - ERR - is_allowed_to_access_attr - [file ipa_pwd_extop.c, line 786]:
>> slapi_access_allowed does not allow READ to ipaProtectedOperation;read_key
>> s!
>> Feb 13 20:53:28 ipaserver ns-slapd: [13/Feb/2018:20:53:28.826357278
>> +]
>> - ERR - ipapwd_getkeytab - [file ipa_pwd_extop.c, line 1646]: Not allowed
>> to retrieve keytab on [IPA$@DOMAIN.COM] as user [fqdn=
>> ipaserver.ipa.domain.com,cn=computers,cn=accounts,dc=ipa,dc=
>> domain,dc=com]!
>> Feb 13 20:53:28 ipaserver sssd: Failed to parse result: Insufficient
>> access
>> rights
>> Feb 13 20:53:28 ipaserver sssd: Failed to get keytab
>>
>> I could paste the the debug logs from sssd but I'm pretty sure that error
>> in /var/log/messages is the root cause preventing AD ssh login. I did some
>> research and couldn't find anything revelant.
>>
>> Any ideas how to fix this ?
>>
> It looks like ipaserver.ipa.domain.com is not a trust agent. Remember
> that only trust agents and trust controllers can retrieve trusted domain
> object credentials to communicate to AD DCs.
>
> --
> / Alexander Bokovoy
>



-- 
Alexandre Pitre
alexandre.pi...@gmail.com
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Trusted AD users can no longer authenticate via SSH

[Alexandre Pitre via FreeIPA-users]

Earlier this week, users reported they could no longer ssh to freeipa
joined servers using their AD login. After some inverstigation, it was
discovered if krb5_validate was set to false in the sssd.conf, AD ssh login
would start working again.

One of our IPA server is showing these errors in /var/log/messages:

Feb 13 20:53:28 ipaserver ns-slapd: [13/Feb/2018:20:53:28.823685558 +]
- ERR - is_allowed_to_access_attr - [file ipa_pwd_extop.c, line 786]:
slapi_access_allowed does not allow READ to ipaProtectedOperation;read_keys!
Feb 13 20:53:28 ipaserver ns-slapd: [13/Feb/2018:20:53:28.826357278 +]
- ERR - ipapwd_getkeytab - [file ipa_pwd_extop.c, line 1646]: Not allowed
to retrieve keytab on [IPA$@DOMAIN.COM] as user [fqdn=
ipaserver.ipa.domain.com,cn=computers,cn=accounts,dc=ipa,dc=domain,dc=com]!
Feb 13 20:53:28 ipaserver sssd: Failed to parse result: Insufficient access
rights
Feb 13 20:53:28 ipaserver sssd: Failed to get keytab

I could paste the the debug logs from sssd but I'm pretty sure that error
in /var/log/messages is the root cause preventing AD ssh login. I did some
research and couldn't find anything revelant.

Any ideas how to fix this ?

Thanks
-- 
Alexandre Pitre
alexandre.pi...@gmail.com
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Login failed due to unknow reason on the WebUI on new FreeIPA 4.5 installation

[Alexandre Pitre via FreeIPA-users]

chmod 644 /etc/ipa/ca.crt
chmod 660 /var/run/ipa/ccaches/admin\@IPA.DOMAIN.COM

Fixed the issue.

The installation was done with a 027 umask. Should I be worried that
something else may have incorrect permissions ?

Thanks for your help everyone
Alex

On Thu, Jan 18, 2018 at 11:22 AM, Rob Crittenden <rcrit...@redhat.com>
wrote:

> Alexandre Pitre via FreeIPA-users wrote:
> > Hi,
> >
> > I recently deployed a new FreeIPA domain running on CentOS 7.4 and
> > FreeIPA 4.5
> >
> > The installation went without hiccups but the WebUI isn't working as
> > expected. Logging in with admin failed with this error:
> >
> > Login failed due to an unknow reason.
> >
> > I've seen this issue with every FreeIPA 4.5 replica I've built. As you
> > may know this is pretty common error with 4.5. I usually just chmod 444
> > /var/lib/ipa-client/pki/* as pointed out
> > in https://access.redhat.com/solutions/3178971 and the logging start
> > working again but not this time with a brand new domain installation.
> >
> > Permissions are correct for the PEM
> > ll /var/lib/pki/*
> > -r--r--r-- 1 root root 4406 Jan  9 14:49 ca-bundle.pem
> > -r--r--r-- 1 root root 4406 Jan  9 14:49 kdc-ca-bundle.pem
> >
> > Here's the output of /var/log/httpd/error_log
> >
> > [Thu Jan 18 01:14:40.543272 2018] [suexec:notice] [pid 12537] AH01232:
> > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
> > [Thu Jan 18 01:14:40.543348 2018] [:warn] [pid 12537]
> > NSSSessionCacheTimeout is deprecated. Ignoring.
> > [Thu Jan 18 01:14:40.766070 2018] [auth_digest:notice] [pid 12537]
> > AH01757: generating secret for digest authentication ...
> > [Thu Jan 18 01:14:40.766623 2018] [lbmethod_heartbeat:notice] [pid
> > 12537] AH02282: No slotmem from mod_heartmonitor
> > [Thu Jan 18 01:14:40.766640 2018] [:warn] [pid 12537]
> > NSSSessionCacheTimeout is deprecated. Ignoring.
> > [Thu Jan 18 01:14:40.843105 2018] [mpm_prefork:notice] [pid 12537]
> > AH00163: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.5.1 mod_nss/1.0.14
> > NSS/3.28.4 mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal
> > operations
> > [Thu Jan 18 01:14:40.843134 2018] [core:notice] [pid 12537] AH00094:
> > Command line: '/usr/sbin/httpd -D FOREGROUND'
> > [Thu Jan 18 01:14:48.465191 2018] [:error] [pid 12545] ipa: INFO: ***
> > PROCESS START ***
> > [Thu Jan 18 01:14:48.470206 2018] [:error] [pid 12546] ipa: INFO: ***
> > PROCESS START ***
> > [Thu Jan 18 01:15:14.020600 2018] [:error] [pid 12545] ipa: INFO: 401
> > Unauthorized: [Errno 13] Permission denied
>
> Check the perms on /etc/ipa/ca.crt as well.
>
> Did you have custom umask set when installing the server?
> > Output of /var/log/messages show weird errors
>
> These are all generally "normal".
>
> rob
>



-- 
Alexandre Pitre
alexandre.pi...@gmail.com
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Login failed due to unknow reason on the WebUI on new FreeIPA 4.5 installation

[Alexandre Pitre via FreeIPA-users]

SELinux is disabled in our CentOS template. Good hypothesis tho.

On Jan 18, 2018 01:36, "Tony Brian Albers via FreeIPA-users" <
freeipa-users@lists.fedorahosted.org> wrote:

> On 01/18/2018 02:24 AM, Alexandre Pitre via FreeIPA-users wrote:
> > Hi,
> >
> > I recently deployed a new FreeIPA domain running on CentOS 7.4 and
> > FreeIPA 4.5
> >
> > The installation went without hiccups but the WebUI isn't working as
> > expected. Logging in with admin failed with this error:
> >
> > Login failed due to an unknow reason.
> >
> > I've seen this issue with every FreeIPA 4.5 replica I've built. As you
> > may know this is pretty common error with 4.5. I usually just chmod 444
> > /var/lib/ipa-client/pki/* as pointed out in
> > https://access.redhat.com/solutions/3178971 and the logging start
> > working again but not this time with a brand new domain installation.
> >
> > Permissions are correct for the PEM
> > ll /var/lib/pki/*
> > -r--r--r-- 1 root root 4406 Jan  9 14:49 ca-bundle.pem
> > -r--r--r-- 1 root root 4406 Jan  9 14:49 kdc-ca-bundle.pem
> >
> > Here's the output of /var/log/httpd/error_log
> >
> > [Thu Jan 18 01:14:40.543272 2018] [suexec:notice] [pid 12537] AH01232:
> > suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
> > [Thu Jan 18 01:14:40.543348 2018] [:warn] [pid 12537]
> > NSSSessionCacheTimeout is deprecated. Ignoring.
> > [Thu Jan 18 01:14:40.766070 2018] [auth_digest:notice] [pid 12537]
> > AH01757: generating secret for digest authentication ...
> > [Thu Jan 18 01:14:40.766623 2018] [lbmethod_heartbeat:notice] [pid
> > 12537] AH02282: No slotmem from mod_heartmonitor
> > [Thu Jan 18 01:14:40.766640 2018] [:warn] [pid 12537]
> > NSSSessionCacheTimeout is deprecated. Ignoring.
> > [Thu Jan 18 01:14:40.843105 2018] [mpm_prefork:notice] [pid 12537]
> > AH00163: Apache/2.4.6 (CentOS) mod_auth_gssapi/1.5.1 mod_nss/1.0.14
> > NSS/3.28.4 mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal
> > operations
> > [Thu Jan 18 01:14:40.843134 2018] [core:notice] [pid 12537] AH00094:
> > Command line: '/usr/sbin/httpd -D FOREGROUND'
> > [Thu Jan 18 01:14:48.465191 2018] [:error] [pid 12545] ipa: INFO: ***
> > PROCESS START ***
> > [Thu Jan 18 01:14:48.470206 2018] [:error] [pid 12546] ipa: INFO: ***
> > PROCESS START ***
> > [Thu Jan 18 01:15:14.020600 2018] [:error] [pid 12545] ipa: INFO: 401
> > Unauthorized: [Errno 13] Permission denied
> >
> > Output of /var/log/messages show weird errors:
> >
> > Jan 18 01:14:36 bo2-tnt-ipa-001 ipa-dnskeysyncd: ipa : ERROR
> > syncrepl_poll: LDAP error ({'desc': "Can't contact LDAP server"})
> > Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd:
> > [18/Jan/2018:01:14:38.102629780 +] - ERR - schema-compat-plugin -
> > scheduled schema-compat-plugin tree scan in about 5 seconds after the
> > server startup!
> > Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd:
> > [18/Jan/2018:01:14:38.115268733 +] - ERR - NSACLPlugin - acl_parse -
> > The ACL target cn=groups,cn=compat,dc=ipa,dc=domain,dc=com does not
> exist
> > Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd:
> > [18/Jan/2018:01:14:38.116680963 +] - ERR - NSACLPlugin - acl_parse -
> > The ACL target cn=computers,cn=compat,dc=ipa,dc=domain,dc=com does not
> exist
> > Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd:
> > [18/Jan/2018:01:14:38.117878580 +] - ERR - NSACLPlugin - acl_parse -
> > The ACL target cn=ng,cn=compat,dc=ipa,dc=domain,dc=com does not exist
> > Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd:
> > [18/Jan/2018:01:14:38.119338367 +] - ERR - NSACLPlugin - acl_parse -
> > The ACL target ou=sudoers,dc=ipa,dc=domain,dc=com does not exist
> > Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd:
> > [18/Jan/2018:01:14:38.120503775 +] - ERR - NSACLPlugin - acl_parse -
> > The ACL target cn=users,cn=compat,dc=ipa,dc=domain,dc=com does not exist
> > Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd:
> > [18/Jan/2018:01:14:38.122000132 +] - ERR - NSACLPlugin - acl_parse -
> > The ACL target cn=vaults,cn=kra,dc=ipa,dc=domain,dc=com does not exist
> > Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd:
> > [18/Jan/2018:01:14:38.123149308 +] - ERR - NSACLPlugin - acl_parse -
> > The ACL target cn=vaults,cn=kra,dc=ipa,dc=domain,dc=com does not exist
> > Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd:
> > [18/Jan/2018:01:14:38.124282277 +] - ERR - NSACLPlugin - acl_parse -
> > The ACL target cn=vaults,cn=kra,dc=ipa,dc=domain,dc=com does not exist
> > Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd:
> > [18/Jan/2018:01:14:38.125837

[Freeipa-users] Login failed due to unknow reason on the WebUI on new FreeIPA 4.5 installation

[Alexandre Pitre via FreeIPA-users]

Hi,

I recently deployed a new FreeIPA domain running on CentOS 7.4 and FreeIPA
4.5

The installation went without hiccups but the WebUI isn't working as
expected. Logging in with admin failed with this error:

Login failed due to an unknow reason.

I've seen this issue with every FreeIPA 4.5 replica I've built. As you may
know this is pretty common error with 4.5. I usually just chmod 444
/var/lib/ipa-client/pki/* as pointed out in
https://access.redhat.com/solutions/3178971 and the logging start working
again but not this time with a brand new domain installation.

Permissions are correct for the PEM
ll /var/lib/pki/*
-r--r--r-- 1 root root 4406 Jan  9 14:49 ca-bundle.pem
-r--r--r-- 1 root root 4406 Jan  9 14:49 kdc-ca-bundle.pem

Here's the output of /var/log/httpd/error_log

[Thu Jan 18 01:14:40.543272 2018] [suexec:notice] [pid 12537] AH01232:
suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Thu Jan 18 01:14:40.543348 2018] [:warn] [pid 12537]
NSSSessionCacheTimeout is deprecated. Ignoring.
[Thu Jan 18 01:14:40.766070 2018] [auth_digest:notice] [pid 12537] AH01757:
generating secret for digest authentication ...
[Thu Jan 18 01:14:40.766623 2018] [lbmethod_heartbeat:notice] [pid 12537]
AH02282: No slotmem from mod_heartmonitor
[Thu Jan 18 01:14:40.766640 2018] [:warn] [pid 12537]
NSSSessionCacheTimeout is deprecated. Ignoring.
[Thu Jan 18 01:14:40.843105 2018] [mpm_prefork:notice] [pid 12537] AH00163:
Apache/2.4.6 (CentOS) mod_auth_gssapi/1.5.1 mod_nss/1.0.14 NSS/3.28.4
mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations
[Thu Jan 18 01:14:40.843134 2018] [core:notice] [pid 12537] AH00094:
Command line: '/usr/sbin/httpd -D FOREGROUND'
[Thu Jan 18 01:14:48.465191 2018] [:error] [pid 12545] ipa: INFO: ***
PROCESS START ***
[Thu Jan 18 01:14:48.470206 2018] [:error] [pid 12546] ipa: INFO: ***
PROCESS START ***
[Thu Jan 18 01:15:14.020600 2018] [:error] [pid 12545] ipa: INFO: 401
Unauthorized: [Errno 13] Permission denied

Output of /var/log/messages show weird errors:

Jan 18 01:14:36 bo2-tnt-ipa-001 ipa-dnskeysyncd: ipa : ERROR
syncrepl_poll: LDAP error ({'desc': "Can't contact LDAP server"})
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.102629780
+] - ERR - schema-compat-plugin - scheduled schema-compat-plugin tree
scan in about 5 seconds after the server startup!
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.115268733
+] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=groups,cn=compat,dc=ipa,dc=domain,dc=com does not exist
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.116680963
+] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=computers,cn=compat,dc=ipa,dc=domain,dc=com does not exist
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.117878580
+] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=ng,cn=compat,dc=ipa,dc=domain,dc=com does not exist
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.119338367
+] - ERR - NSACLPlugin - acl_parse - The ACL target
ou=sudoers,dc=ipa,dc=domain,dc=com does not exist
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.120503775
+] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=users,cn=compat,dc=ipa,dc=domain,dc=com does not exist
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.122000132
+] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=domain,dc=com does not exist
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.123149308
+] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=domain,dc=com does not exist
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.124282277
+] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=domain,dc=com does not exist
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.125837472
+] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=domain,dc=com does not exist
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.126966928
+] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=domain,dc=com does not exist
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.128085824
+] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=domain,dc=com does not exist
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.129501796
+] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=domain,dc=com does not exist
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.130686657
+] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=domain,dc=com does not exist
Jan 18 01:14:38 bo2-tnt-ipa-001 ns-slapd: [18/Jan/2018:01:14:38.132301267
+] - ERR - NSACLPlugin - acl_parse - The ACL target
cn=vaults,cn=kra,dc=ipa,dc=domain,dc=com does not exist
Jan 18 01:14:38 bo2-tnt-ipa-001 

[Freeipa-users] Re: User login is slow to get password prompt

[Alexandre Pitre via FreeIPA-users]

Hi Jakub,

Thanks for your response. I assume our puppet configuration was incomplete
and ldap_search_base = cn=accounts,dc=ipa,dc=domain,dc=com was left out by
mistake. We're already using the trusted domain section to force connection
to AD site-specific domain controllers. Is ad_site parameter useful only if
we we relying on DNS discovery ? See our sssd.conf full configuration
below.


Server side:

[domain/ipa.domain.com]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.domain.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname = ipa-001.ipa.domain.com
chpass_provider = ipa
ipa_server = ipa-001.ipa.domain.com
ipa_server_mode = True
ignore_group_members = True
subdomain_inherit = ignore_group_members

[sssd]
services = nss, sudo, pam, ssh
domains = ipa.domain.com

[domain/ipa.domain.com/domain.com]
ad_server = ad-001.domain.com
ad_backup_server = ad-002.domain.com

[nss]
homedir_substring = /home
override_shell = /bin/bash

[pam]

[sudo]

[autofs]

[ssh]

[pac]

[ifp]


Client side:

[domain/ipa.domain.com]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.domain.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname = centos.ipa.domain.com
chpass_provider = ipa
dyndns_update = True
ipa_server = _srv_, ipa-001.ipa.domain.com, ipa-002.ipa.domain.com
dyndns_iface = eth0

[sssd]
services = nss, sudo, pam, ssh
domains = ipa.domain.com,domain.com

[nss]
homedir_substring = /home
override_shell = /bin/bash

[pam]
pam_id_timeout = 120

[sudo]

[autofs]

[ssh]

[pac]

[ifp]

My colleague added this section as a test and this seems to have fixed our
login slowness with AD credentials.

[domain/domain.com]
auth_provider = krb5
cache_credentials = True
ldap_id_use_start_tls = False
krb5_server = ad-001.domain.com:88
krb5_kpasswd = ad-002.domain.com:88
ldap_search_base = OU=Accounts,DC=domain,DC=com
krb5_realm = DOMAIN.COM
chpass_provider = none
id_provider = ldap
krb5_canonicalize = false

Is this a good practice ?

Thanks,
Alex

On Tue, Dec 19, 2017 at 5:13 AM, Jakub Hrozek via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> On Mon, Dec 18, 2017 at 06:59:25PM -0500, Alexandre Pitre via
> FreeIPA-users wrote:
> > Hi,
> >
> > While troubleshooting "slow login" with ipa users we discovered that
> adding
> > these two lines to our clients sssd.conf file fixed our issue for ipa
> users.
> >
> > ldap_search_base = cn=accounts,dc=ipa,dc=domain,dc=com
>
> This should already be the default
>
> > ldap_user_search_base = cn=users,cn=accounts,dc=ipa,dc=domain,dc=com
>
> This is not, but does it really make much of a difference? By default,
> both the user and group search bases are set to
> cn=accounts,dc=ipa,dc=domain,dc=com
>
>
> >
> > On the freeipa server side's sssd, we also added, based on the
> performance
> > tuning blog post
> > https://jhrozek.wordpress.com/2015/08/19/performance-tuning-
> sssd-for-large-ipa-ad-trust-deployments/,
> > these two parameters.
> >
> > ignore_group_members = True
> > subdomain_inherit = ignore_group_members
> >
>
> I think this is what makes the difference
>
> > Without these options and sssd debug enabled, we can see that it goes
> > through all the trusted AD group to request membership(I think).
> >
> > Here's a log entry example:
> >
> > (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]]
> > [ipa_s2n_get_list_next] (0x0400): Received [testgr...@domain.com]
> > attributes from IPA server.
> > (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]]
> > [ipa_s2n_save_objects] (0x0400): Processing group testgr...@domain.com
> > (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]]
> > [sysdb_search_by_name] (0x0400): No such entry
> > (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]]
> > [sysdb_search_by_name] (0x0400): No such entry
> > (Mon Dec 18 23:50:49 2017) [sssd[be[ipa.domain.com]]]
> > [sysdb_search_group_by_gid] (0x0400): No such entry
> >
> > Should ldap_search_base and lda_user_seach_base parameters should be in
> our
> > clients sssd per default ? Is that a normal behavior ?
>
> Yes, currently the group resolution is not super fast in a large domain.
> But we've added some performance improvements in the 1.16.x branch of
> SSSD which should make its way (at least to) RHEL-7.5
>
> >
> > We're also experiencing similar login slowness with our AD trusted
> > credentials. Do similar parameters exist for a trusted AD realm ?
>
> Some parameters for the trusted domains can be set in the trusted domain
> section directly, e

[Freeipa-users] Re: Directory service stop and won't stay up when restarted

[Alexandre Pitre via FreeIPA-users]

Hi Ludwig,

Thanks for your reply. We decided earlier today to restore from backup,
that wasn't without issues but we had to get production back up running
asap. I believe I fixed all the issues post backup restore and we seem to
be in good shape now.

We're looking at migrating to redhat idm in the future as we can't afford
facing such critical issues like that.

Thanks to Alexander Bokovoy on IRC as well for providing backup restore
instructions.

Regards,
Alex

On Wed, Nov 29, 2017 at 4:18 AM, Ludwig Krispenz via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> The crash looks very much like the one found in
> https://pagure.io/389-ds-base/issue/48894
> it is fixed and the code has also been generally improved with:
> https://pagure.io/389-ds-base/issue/49401
>
> As far as I can see these patches are not in 1.3.6.1-21, they are in
> upstream 1.3.6.10.
>
> If you cannot get a version containing these patches, you could try to
> cleanup the entry state information by export/import reinitialize. It would
> mean on on server export the data to ldif without replication meta data and
> reimport it. But this changes the data generation and other replicas have
> to be reinitialized for replication to work again
>
> Ludwig
>
> On 11/28/2017 04:37 AM, Alexandre Pitre via FreeIPA-users wrote:
>
> I managed to remove the replication conflicts but the orignal issue
> persist. I found a couple of triggers that crash the directory service,
> regardless of the freeipa server location. Here are the triggers:
>
>- Deleting a host that exist in freeipa but no longer exist in our
>infrastructure
>- Deleting the same host from an hostgroup
>- Re-building the auto membership of the hosts
>
> What worry me the most is that I can't even delete the "dead hosts" from
> the ldap backend cn=computers OU...it crash the directory service as well.
>
> Attached you'll find the stack trace generated from a core dump.
>
> Please help.
>
> Thanks
>
>
>
>
> On Sun, Nov 26, 2017 at 11:06 PM, Alexandre Pitre <
> alexandre.pi...@gmail.com> wrote:
>
>> I believe I found the root cause.There are replication conflicts.
>>
>> ldapsearch -x -D "cn=directory manager" -w password -b
>> "dc=ipa,dc=domain,dc=com" "nsds5ReplConflict=*" \* nsds5ReplConflict
>>
>> # extended LDIF
>> #
>> # LDAPv3
>> # base 

[Freeipa-users] Directory service stop and won't stay up when restarted

[Alexandre Pitre via FreeIPA-users]

Hi,

I had two freeipa replica servers up and running in our german DC for
nearly 2 months and this morning out of the blue they stopped working.

Looking at ipactl status, both servers are reporting that their directory
service is stopped. Trying to restart ipa only works from 2 minutes to an
hour.

Looking at the /var/log/dirsrv/slapd-DOMAIN-COM/errors there's no errors
that show up before it crash.

However, looking at /var/log/messages, this lovely segfault show up:

XX kernel: ns-slapd[17507]: segfault at 8 ip 7fb99e56149f sp
7fb96bee83c0 error 4 in libslapd.s
o.0.1.0[7fb99e483000+128000]

Out of despair to get production back up and running quickly, I reinstalled
one replica...it worked for an hour and came back with the same issue.

We have 6 other freeipa replica running accross 3 different site with zero
issues.

We're running CentOS 7.4 with the latest packages, ipa-server-4.5.0-21 &
389-ds-base-1.3.6.1-21.

Any clues why ?

Thanks

-- 
Alexandre Pitre
alexandre.pi...@gmail.com
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ipa sudorule-add-user SUDORULE-NAME doesn't support multiple groups

[Alexandre Pitre via FreeIPA-users]

Would you look at that! Problem solved.Thanks.

On Tue, Oct 24, 2017 at 12:08 PM, Rob Crittenden <rcrit...@redhat.com>
wrote:

> Alexandre Pitre via FreeIPA-users wrote:
> > Hi,
> >
> > I noticed that on FreeIPA 4.5.0 on CentOS I can't specify multiple
> > groups with the sudorule-add-user command.
> >
> > Example:
> >
> > ipa sudorule-add-user sudorule --groups=group1,group2
> >
> >  Failed users/groups:
> > member user:
> > member group: group1,group2
> > -
> > Number of members added 0
> > -
> >
> > Other similar ipa commands support multiple groups just fine.
> >
> > Is this normal ?
>
> CSV hasn't been supported for quite a long time. I'd be curious where it
> is still working.
>
> You can do let bash expand it instead:
>
> ipa sudorule-add-user sudorule --groups={group1,group2}
>
> rob
>



-- 
Alexandre Pitre
alexandre.pi...@gmail.com
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] ipa sudorule-add-user SUDORULE-NAME doesn't support multiple groups

[Alexandre Pitre via FreeIPA-users]

Hi,

I noticed that on FreeIPA 4.5.0 on CentOS I can't specify multiple groups
with the sudorule-add-user command.

Example:

ipa sudorule-add-user sudorule --groups=group1,group2

 Failed users/groups:
member user:
member group: group1,group2
-
Number of members added 0
-

Other similar ipa commands support multiple groups just fine.

Is this normal ?

Thanks,
Alex
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

[Alexandre Pitre via FreeIPA-users]

Hi Alexander,

You're correct, turns out I wasn't using the correct domain for the
--domain parameter. I thought I was. Here's the command I used.

ipa-client-install -U -p admin -w Passw0rd! --enable-dns-updates --mkhomedir
 --domain=ipa.ad.com --realm=IPA.AD.COM --no-ntp --debug

All of my client hostname are set as "hostname.domain.ad.com", I didn't
 know that in itself that was enough of a requirement to join them to
FreeIPA. Of course, given that the domain is also present in freeipa and
the AD trust has been established AFTER the domain was added to freeipa.

I haven't tested yet without the realm parameter. It is possible that I
don't need --domain nor --realm parameters ? Does that require the creation
of *_ldap._tcp.* srv records in domain.ad.com dns zone?

Taken from the man page:

*When the client machine hostname is not in a subdomain of an IPA server,
its domain can be passed with --domain
<https://www.mankier.com/1/ipa-client-install#--domain> option. In that
case, both SSSD and Kerberos components have the domain set in the
configuration files and will use it to autodiscover IPA servers.*

That line miss directed me, not sure if that's my interpretation.
Documentation could benefit from being clearer and having examples.

Setting krb5_auth_timeout to 120 seconds is also required in my environment
as we're dealing with AD DC spreaded all over the globe. To make kerberos
negotiation faster, I assume I could specify my AD.COM realm in
/etc/krb5.conf with my local site AD DC ?

Big thanks to you and Jakub, my employer and I are very glad that this
issue is finally resolved =)


On Tue, Aug 15, 2017 at 3:45 AM, Alexander Bokovoy <aboko...@redhat.com>
wrote:

> On ma, 14 elo 2017, Alexandre Pitre via FreeIPA-users wrote:
>
>> Although, the explanation from Alexander Bokovoy made perfect sense, I'm
>> still facing the issue after I re-established the AD trust successfully:
>>
>> (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sdap_cli_auth_step]
>> (0x1000): the connection will expire at 1502764720
>> (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
>> (0x0100): Executing sasl bind mech: GSSAPI, user: host/
>> centos.domain.ad.com
>> (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
>> (0x0020): ldap_sasl_bind failed (-2)[Local error]
>> (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
>> (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI
>> Error: Unspecified GSS failure.  Minor code may provide more information
>> (Server krbtgt/ad@tenant.ad.com not found in Kerberos database)]
>>
> Why do you use domain.ad.com as IPA domain here? Your IPA domain should
> be 'ipa.ad.com' when you enroll clients regardless which DNS domains
> they belong to. It is the realm they will be attached, so your sssd.conf
> on the machines in domain.ad.com should have
>
> [domain/ipa.ad.com]
> ipa_domain = ipa.ad.com
>
> And the client enrollment should use IPA domain too:
>
>  ipa-client-install --domain ipa.ad.com
>
> Read http://www.freeipa.org/page/V4/IPA_Client_in_Active_Director
> y_DNS_domain for more.
>
> Because your configuration now is wrong, krb5 library thinks your client
> is part of DOMAIN.AD.COM realm (TENANT.AD.COM in the log above, I guess
> you did not scrub it well) and not IPA.AD.COM instead. This is why it
> fails to find a cross-realm TGT to traverse up from DOMAIN.AD.COM to
> AD.COM realm hierarchically. Obviously, it should not be doing that.
>
>
>
> (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [child_sig_handler]
>> (0x1000): Waiting for child [5197].
>> (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [child_sig_handler]
>> (0x0100): child [5197] finished successfully.
>> (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
>> [sdap_cli_connect_recv] (0x0040): Unable to establish connection
>> [1432158225]: Authentication Failed
>> (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
>> [_be_fo_set_port_status] (0x8000): Setting status: PORT_NOT_WORKING.
>> Called
>> from: src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_recv:
>> 2048
>> (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_set_port_status]
>> (0x0100): Marking port 0 of server 'ipaserver02.ipa.ad.com' as 'not
>> working'
>> (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_set_port_status]
>> (0x0400): Marking port 0 of duplicate server 'ipaserver02.ipa.ad.com' as
>> 'not working'
>> (Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
>> [sdap_handle_release]
>> (0x2000): Trace: sh[0x7f4811278710], connected[1], ops[(nil)],
>> ldap[0x7f481121f780], destructor_lock[0], release_me

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

[Alexandre Pitre via FreeIPA-users]

Although, the explanation from Alexander Bokovoy made perfect sense, I'm
still facing the issue after I re-established the AD trust successfully:

(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sdap_cli_auth_step]
(0x1000): the connection will expire at 1502764720
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
(0x0100): Executing sasl bind mech: GSSAPI, user: host/centos.domain.ad.com
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
(0x0020): ldap_sasl_bind failed (-2)[Local error]
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
(0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI
Error: Unspecified GSS failure.  Minor code may provide more information
(Server krbtgt/ad@tenant.ad.com not found in Kerberos database)]
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [child_sig_handler]
(0x1000): Waiting for child [5197].
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [child_sig_handler]
(0x0100): child [5197] finished successfully.
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[sdap_cli_connect_recv] (0x0040): Unable to establish connection
[1432158225]: Authentication Failed
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[_be_fo_set_port_status] (0x8000): Setting status: PORT_NOT_WORKING. Called
from: src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_recv:
2048
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_set_port_status]
(0x0100): Marking port 0 of server 'ipaserver02.ipa.ad.com' as 'not working'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_set_port_status]
(0x0400): Marking port 0 of duplicate server 'ipaserver02.ipa.ad.com' as
'not working'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [sdap_handle_release]
(0x2000): Trace: sh[0x7f4811278710], connected[1], ops[(nil)],
ldap[0x7f481121f780], destructor_lock[0], release_memory[0]
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[remove_connection_callback] (0x4000): Successfully removed connection
callback.
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[sdap_id_op_connect_done] (0x4000): attempting failover retry on op #1
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[sdap_id_op_connect_step] (0x4000): beginning to connect
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [get_port_status]
(0x1000): Port status of port 0 for server '(no name)' is 'neutral'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6
seconds
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [resolve_srv_send]
(0x0200): The status of SRV lookup is neutral
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[resolv_discover_srv_next_domain] (0x0400): SRV resolution of service
'ldap'. Will use DNS discovery domain 'domain.ad.com'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [resolv_getsrv_send]
(0x0100): Trying to resolve SRV record of '_ldap._tcp.domain.ad.com'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[sdap_id_release_conn_data] (0x4000): releasing unused connection
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[request_watch_destructor] (0x0400): Deleting request watch
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[resolv_discover_srv_done] (0x0040): SRV query failed [4]: Domain name not
found
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [fo_set_port_status]
(0x0100): Marking port 0 of server '(no name)' as 'not working'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [resolve_srv_done]
(0x0040): Unable to resolve SRV [1432158235]: SRV record not found
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [set_srv_data_status]
(0x0100): Marking SRV lookup of service 'IPA' as 'not resolved'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[be_resolve_server_process] (0x0080): Couldn't resolve server (SRV lookup
meta-server), resolver returned [1432158235]: SRV record not found
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[be_resolve_server_process] (0x1000): Trying with the next one!
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]]
[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [get_server_status]
(0x1000): Status of server 'ipaserver01.ipa.ad.com' is 'name resolved'
(Tue Aug 15 02:23:40 2017) [sssd[be[domain.ad.com]]] [get_port_status]
(0x1000): Port status of port 0 for server 'ipaserver01.ipa.ad.com' is 'not

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

[Alexandre Pitre via FreeIPA-users]

If your hosts are in the IPA subdomain, then I would have expected
centos.ipa.ad.com

The centos client has a hostname set to centos.domain.ad.com I'm using FQDN
hostname based on the required DNS domain, not the IPA kerberos realm.
Hence why centos.domain.ad.com.

To explain further more, It'll probably be easier to use ipa.ad.com for all
for my clients and not deal with a different DNS domain than the IPA realm.
However, we have this business requirement to use a a different domain than
the IPA realm. My understanding is that supposed to be supported by using
the --domain switch of ipa-client-install:
http://www.unix.com/man-page/centos/1/ipa-client-install/ which basically
just add static entires in /etc/sssd/sssd.conf and /etc/krb5.conf

Should I approach things differently ?


What is the relation between domain.ad.com and ad.com and ipa.ad.com?

ad.com is my Active Directory domain.
domain.ad.com is a sub domain that was delegated from the AD DNS to the
freeipa servers
ipa.ad.com is also a sub domain that was delegated from the AD DNS to the
freeipa servers and is the freeipa native kerberos realm.



On Wed, Aug 9, 2017 at 9:55 AM, Jakub Hrozek <jhro...@redhat.com> wrote:

>
> On 7 Aug 2017, at 20:02, Alexandre Pitre via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
> The client is in the IPA domain. Although it's sub-domain of ad.com, I
> did delegate it and configure the IPA servers as name servers.  It uses a
> different domain suffix than ipa realm which was specified by
> ipa-client-install:
>
>
> OK, but in the logs, I see:
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
> (0x0100): Executing sasl bind mech: GSSAPI, user: host/
> centos.domain.ad.com
>
> —> centos.domain.ad.com
>
> If your hosts are in the IPA subdomain, then I would have expected
> centos.ipa.ad.com
>
> What is the relation between domain.ad.com and ad.com and ipa.ad.com?
>
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
> (0x0020): ldap_sasl_bind failed (-2)[Local error]
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
> (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI
> Error: Unspecified GSS failure.  Minor c
> ode may provide more information (Server krbtgt/ad@ipa.ad.com not
> found in Kerberos database)]
>
> ipa-client-install -U -p admin -w Passw0rd! --enable-dns-updates
> --mkhomedir --domain=domain.ad.com --realm=IPA.AD.COM <http://ipa.ad.com/>
>  --server=ipaserver01.ipa.ad.com --server=ipaserver02.ipa.ad.com --no-ntp
> --debug
>
>
>
> On Mon, Aug 7, 2017 at 1:00 PM, Jakub Hrozek <jhro...@redhat.com> wrote:
>
>>
>> On 7 Aug 2017, at 18:11, Alexandre Pitre <alexandre.pi...@gmail.com>
>> wrote:
>>
>> Clearing the sssd cache make the AD login works for a short while, it's
>> probably not necessary nor "production" ready. Looking at /var/log/sssd/
>> sssd_domain.ad.com.
>>
>>
>> Sure, but that’s not what I meant. What I meant is that just “systemctl
>> restart sssd” clears the online/offline state.
>>
>> Removing the sssd cache is not needed and can actually be quite
>> dangerous. I wish people just stopped doing that, because in case
>> credentials are cached, removing the cache also removes the credentials,
>> leaving users with no way to authenticate.
>>
>> I do see offline messages:
>>
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
>> [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5
>> [Input/output error])
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_mark_offline]
>> (0x2000): Going offline!
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_mark_offline]
>> (0x2000): Enable check_if_online_ptask.
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_enable]
>> (0x0400): Task [Check if online (periodic)]: enabling task
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_schedule]
>> (0x0400): Task [Check if online (periodic)]: scheduling task 65 seconds
>> from now [1502119252]
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_run_offline_cb]
>> (0x0080): Going offline. Running callbacks.
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
>> [sdap_id_op_connect_done] (0x4000): notify offline to op #1
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
>> [ipa_subdomains_refresh_connect_done] (0x0020): Unable to connect to
>> LDAP [11]: Resource temporarily unavailable
>> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
>> [ipa_subdomains_refresh_connect_done] (0x0080): No IPA server is
>> avail

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

[Alexandre Pitre via FreeIPA-users]

The client is in the IPA domain. Although it's sub-domain of ad.com, I did
delegate it and configure the IPA servers as name servers.  It uses a
different domain suffix than ipa realm which was specified by
ipa-client-install:

ipa-client-install -U -p admin -w Passw0rd! --enable-dns-updates
--mkhomedir --domain=domain.ad.com --realm=IPA.AD.COM --server=
ipaserver01.ipa.ad.com --server=ipaserver02.ipa.ad.com --no-ntp --debug



On Mon, Aug 7, 2017 at 1:00 PM, Jakub Hrozek <jhro...@redhat.com> wrote:

>
> On 7 Aug 2017, at 18:11, Alexandre Pitre <alexandre.pi...@gmail.com>
> wrote:
>
> Clearing the sssd cache make the AD login works for a short while, it's
> probably not necessary nor "production" ready. Looking at /var/log/sssd/
> sssd_domain.ad.com.
>
>
> Sure, but that’s not what I meant. What I meant is that just “systemctl
> restart sssd” clears the online/offline state.
>
> Removing the sssd cache is not needed and can actually be quite dangerous.
> I wish people just stopped doing that, because in case credentials are
> cached, removing the cache also removes the credentials, leaving users with
> no way to authenticate.
>
> I do see offline messages:
>
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
> [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5
> [Input/output error])
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_mark_offline]
> (0x2000): Going offline!
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_mark_offline]
> (0x2000): Enable check_if_online_ptask.
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_enable]
> (0x0400): Task [Check if online (periodic)]: enabling task
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_schedule]
> (0x0400): Task [Check if online (periodic)]: scheduling task 65 seconds
> from now [1502119252]
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_run_offline_cb]
> (0x0080): Going offline. Running callbacks.
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
> [sdap_id_op_connect_done] (0x4000): notify offline to op #1
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
> [ipa_subdomains_refresh_connect_done] (0x0020): Unable to connect to LDAP
> [11]: Resource temporarily unavailable
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
> [ipa_subdomains_refresh_connect_done] (0x0080): No IPA server is
> available, cannot get the subdomain list while offline
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_done]
> (0x0040): Task [Subdomains Refresh]: failed with [1432158212]: SSSD is
> offline
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_schedule]
> (0x0400): Task [Subdomains Refresh]: scheduling task 14400 seconds from now
> [1502133587]
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
> [sdap_id_release_conn_data] (0x4000): releasing unused connection
> (Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_online_cb]
> (0x0400): Back end is online
>
> I uploaded  the full log file /var/log/sssd/sssd_domain.ad.com
> https://1drv.ms/f/s!AlZwwyQE2ZZ5p2ZmHLzmeKN7mBJ3
>
> Both my IPA servers looks healthy.AD trust agent/controller server role
> are installed on both.
>
> ipa trustdomain-find ad.com does return all of my AD domains on both IPA
> servers.
>
>
> This is the failure in the logs:
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]]
> [sdap_process_result] (0x2000): Trace: end of ldap_result list
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [write_pipe_handler]
> (0x0400): All data has been sent!
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [read_pipe_handler]
> (0x0400): EOF received, client finished
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sdap_get_tgt_recv]
> (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_IPA.AD.COM],
> expired on [1502203793]
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sdap_cli_auth_step]
> (0x0100): expire timeout is 900
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sdap_cli_auth_step]
> (0x1000): the connection will expire at 1502118293
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
> (0x0100): Executing sasl bind mech: GSSAPI, user: host/
> centos.domain.ad.com
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
> (0x0020): ldap_sasl_bind failed (-2)[Local error]
> (Mon Aug  7 14:49:53 2017) [sssd[be[domain.ad.com]]] [sasl_bind_send]
> (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI
> Error: Unspecified GSS failure.  Minor c
> ode may provide more information (Server krbtgt/ad@ipa.ad.com not
> found in Kerberos database)]
>
> Is your client hostname in the AD d

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

[Alexandre Pitre via FreeIPA-users]

Clearing the sssd cache make the AD login works for a short while, it's
probably not necessary nor "production" ready. Looking at /var/log/sssd/
sssd_domain.ad.com. I do see offline messages:

(Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
[sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5
[Input/output error])
(Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_mark_offline]
(0x2000): Going offline!
(Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_mark_offline]
(0x2000): Enable check_if_online_ptask.
(Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_enable]
(0x0400): Task [Check if online (periodic)]: enabling task
(Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_schedule]
(0x0400): Task [Check if online (periodic)]: scheduling task 65 seconds
from now [1502119252]
(Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_run_offline_cb]
(0x0080): Going offline. Running callbacks.
(Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
[sdap_id_op_connect_done] (0x4000): notify offline to op #1
(Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
[ipa_subdomains_refresh_connect_done] (0x0020): Unable to connect to LDAP
[11]: Resource temporarily unavailable
(Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
[ipa_subdomains_refresh_connect_done] (0x0080): No IPA server is available,
cannot get the subdomain list while offline
(Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_done]
(0x0040): Task [Subdomains Refresh]: failed with [1432158212]: SSSD is
offline
(Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_schedule]
(0x0400): Task [Subdomains Refresh]: scheduling task 14400 seconds from now
[1502133587]
(Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]]
[sdap_id_release_conn_data] (0x4000): releasing unused connection
(Mon Aug  7 15:19:47 2017) [sssd[be[domain.ad.com]]] [be_ptask_online_cb]
(0x0400): Back end is online

I uploaded  the full log file /var/log/sssd/sssd_domain.ad.com
https://1drv.ms/f/s!AlZwwyQE2ZZ5p2ZmHLzmeKN7mBJ3

Both my IPA servers looks healthy.AD trust agent/controller server role are
installed on both.

ipa trustdomain-find ad.com does return all of my AD domains on both IPA
servers.

Thanks,
Alex








On Sun, Aug 6, 2017 at 11:07 AM, Jakub Hrozek <jhro...@redhat.com> wrote:

>
> On 4 Aug 2017, at 23:08, Alexandre Pitre via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
>
> Turns out, I'm still getting the same problem. It works right away after I
> force clean the sssd cache: systemctl stop sssd ; rm -f /var/lib/sss/db/*
> /var/log/sssd/* ; systemctl start sssd
>
> After some time, trying to log back on the same system I see the login
> prompt is much quicker when I type adu...@ad.com
> Instead of getting a simple "Password:" prompt  I get adu...@ad.com@
> centos.domain.ad.com's password.
>
> If I login as root and stop/start and clean the sssd cache, it start
> working again.
>
>
> Are you sure cleaning the cache is needed? Because I think your issue is
> different. The fact that you get a faster login prompt and the “Server not
> found…” message both point to the sssd going offline.
>
> You could run ‘sssctl domain-status’ to show if the domain is online or
> offline (requires the ‘ifp’ service to be enabled until RHEL-7.4/upstream
> 1.15.x) or look into the logs for messages like “Going offline”.
>
> /var/log/messages is filled with:
>
> centos sssd_be: GSSAPI Error: Unspecified GSS failure.  Minor code may
> provide more information (Server krbtgt/ad@ipa.ad.com not found in
> Kerberos database)
>
>
> This is the trust principal. Are you sure all your replicas are either
> trust agents or you ran “ipa-adtrust-install” on them?
>
>
>
> Any thoughts ?
>
> Thanks,
> Alex
>
>
> On Tue, Aug 1, 2017 at 2:58 AM, Jakub Hrozek <jhro...@redhat.com> wrote:
>
>> On Mon, Jul 31, 2017 at 05:47:11PM -0400, Alexandre Pitre wrote:
>> > Bull-eye Jakub, that did the trick. I should have posted for help on the
>> > mailing list sooner. Thanks you so much, you are saving my ass.
>> >
>> > It makes sense to increase the krb5_auth_timeout as my AD domain
>> > controllers servers are worldwide. Currently they exist in 3 regions:
>> North
>> > America, Europe and Asia.
>> >
>> > The weird thing is it seems that when a linux host try to authenticate
>> > against my AD, it just randomly select an AD DC from the _kerberos  SRV
>> > records. Normally, on the windows side, if "sites and services" are
>> setup
>> > correctly with subnet defined and binded to sites, a windows client
>> > shouldn't try to authenticate against an AD DC that isn't local to his
>> > site. This m

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

[Alexandre Pitre via FreeIPA-users]

Turns out, I'm still getting the same problem. It works right away after I
force clean the sssd cache: systemctl stop sssd ; rm -f /var/lib/sss/db/*
/var/log/sssd/* ; systemctl start sssd

After some time, trying to log back on the same system I see the login
prompt is much quicker when I type adu...@ad.com
Instead of getting a simple "Password:" prompt  I get adu...@ad.com@
centos.domain.ad.com's password.

If I login as root and stop/start and clean the sssd cache, it start
working again.

/var/log/messages is filled with:

centos sssd_be: GSSAPI Error: Unspecified GSS failure.  Minor code may
provide more information (Server krbtgt/ad@ipa.ad.com not found in
Kerberos database)


Any thoughts ?

Thanks,
Alex


On Tue, Aug 1, 2017 at 2:58 AM, Jakub Hrozek  wrote:

> On Mon, Jul 31, 2017 at 05:47:11PM -0400, Alexandre Pitre wrote:
> > Bull-eye Jakub, that did the trick. I should have posted for help on the
> > mailing list sooner. Thanks you so much, you are saving my ass.
> >
> > It makes sense to increase the krb5_auth_timeout as my AD domain
> > controllers servers are worldwide. Currently they exist in 3 regions:
> North
> > America, Europe and Asia.
> >
> > The weird thing is it seems that when a linux host try to authenticate
> > against my AD, it just randomly select an AD DC from the _kerberos  SRV
> > records. Normally, on the windows side, if "sites and services" are setup
> > correctly with subnet defined and binded to sites, a windows client
> > shouldn't try to authenticate against an AD DC that isn't local to his
> > site. This mechanism doesn't  seem to apply to my linux hosts. Is it
> > because it's only available for windows hosts ? Is there another way to
> > force linux clients to authenticate against AD DC local to their site ?
>
> We haven't implemented the site selection for the clients yet, only for
> servers, see:
> https://bugzilla.redhat.com/show_bug.cgi?id=1416528
>
> >
> > For now, I set the krb5_auth_timeout to 120 seconds. I had to completely
> > stop sssd and start it again. A colleague mentioned that sssd has a known
> > issue with restart apparently.
>
> I'm not aware of any such issue..
>
> >
> > Also, I'm curious about ports requirements. Going from linux hosts to
> AD, I
> > only authorize 88 TCP/UDP. I believe that's all I need.
>
> Yes, from the clients, that should be enough. The servers need more
> ports open:
> https://access.redhat.com/documentation/en-US/Red_Hat_
> Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_
> Guide/installing-ipa.html#prereq-ports
>



-- 
Alexandre Pitre
alexandre.pi...@gmail.com
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Can’t SSH with AD user to freeipa joined Centos client

[Alexandre Pitre via FreeIPA-users]

Bull-eye Jakub, that did the trick. I should have posted for help on the
mailing list sooner. Thanks you so much, you are saving my ass.

It makes sense to increase the krb5_auth_timeout as my AD domain
controllers servers are worldwide. Currently they exist in 3 regions: North
America, Europe and Asia.

The weird thing is it seems that when a linux host try to authenticate
against my AD, it just randomly select an AD DC from the _kerberos  SRV
records. Normally, on the windows side, if "sites and services" are setup
correctly with subnet defined and binded to sites, a windows client
shouldn't try to authenticate against an AD DC that isn't local to his
site. This mechanism doesn't  seem to apply to my linux hosts. Is it
because it's only available for windows hosts ? Is there another way to
force linux clients to authenticate against AD DC local to their site ?

For now, I set the krb5_auth_timeout to 120 seconds. I had to completely
stop sssd and start it again. A colleague mentioned that sssd has a known
issue with restart apparently.

Also, I'm curious about ports requirements. Going from linux hosts to AD, I
only authorize 88 TCP/UDP. I believe that's all I need.

Thanks,
Alex

On Jul 27, 2017 04:08, "Jakub Hrozek via FreeIPA-users" <
freeipa-users@lists.fedorahosted.org> wrote:

> On Thu, Jul 27, 2017 at 02:34:06AM -0400, Alexandre Pitre via
> FreeIPA-users wrote:
> > I uploaded krb5_child.log and ldap_child.log to
> > https://1drv.ms/f/s!AlZwwyQE2ZZ5p2b5ROa15PBkAEQD
>
> I think the child just times out during TGT validation, see:
> (Thu Jul 27 06:01:20 2017) [[sssd[krb5_child[2765
> [sss_child_krb5_trace_cb] (0x4000): [2765] 1501135280.837647: Sending
> request (2132 bytes) to AD.COM
> (Thu Jul 27 06:01:20 2017) [[sssd[krb5_child[2765
> [sss_child_krb5_trace_cb] (0x4000): [2765] 1501135280.838622: Resolving
> hostname RO1-INF-ADS-002.ad.com.
> (Thu Jul 27 06:01:20 2017) [[sssd[krb5_child[2765
> [sss_child_krb5_trace_cb] (0x4000): [2765] 1501135280.839154: Sending
> initial UDP request to dgram 10.248.40.11:88
> (Thu Jul 27 06:01:21 2017) [[sssd[krb5_child[2765
> [sss_child_krb5_trace_cb] (0x4000): [2765] 1501135281.840215: Resolving
> hostname ns1-inf-ads-001.ad.com.
> (Thu Jul 27 06:01:21 2017) [[sssd[krb5_child[2765
> [sss_child_krb5_trace_cb] (0x4000): [2765] 1501135281.841223: Sending
> initial UDP request to dgram 10.3.200.10:88
> (Thu Jul 27 06:01:22 2017) [[sssd[krb5_child[2765
> [sss_child_krb5_trace_cb] (0x4000): [2765] 1501135282.842291: Resolving
> hostname inf-p-sy2-ad-01.ad.com.
> (Thu Jul 27 06:01:22 2017) [[sssd[krb5_child[2765
> [sss_child_krb5_trace_cb] (0x4000): [2765] 1501135282.843245: Sending
> initial UDP request to dgram 192.168.1.10:88
> (Thu Jul 27 06:01:23 2017) [[sssd[krb5_child[2765
> [sss_child_krb5_trace_cb] (0x4000): [2765] 1501135283.844311: Resolving
> hostname inf-p-sy2-ad-02.ad.com.
> (Thu Jul 27 06:01:23 2017) [[sssd[krb5_child[2765
> [sss_child_krb5_trace_cb] (0x4000): [2765] 1501135283.845251: Sending
> initial UDP request to dgram 192.168.1.11:88
> (Thu Jul 27 06:01:24 2017) [[sssd[krb5_child[2765
> [sss_child_krb5_trace_cb] (0x4000): [2765] 1501135284.846318: Resolving
> hostname RO1-INF-ADS-001.ad.com.
> (Thu Jul 27 06:01:24 2017) [[sssd[krb5_child[2765
> [sss_child_krb5_trace_cb] (0x4000): [2765] 1501135284.847243: Sending
> initial UDP request to dgram 10.248.40.10:88
> (Thu Jul 27 06:01:25 2017) [[sssd[krb5_child[2765
> [sss_child_krb5_trace_cb] (0x4000): [2765] 1501135285.848311: Resolving
> hostname ns1-inf-ads-002.ad.com.
> (Thu Jul 27 06:01:25 2017) [[sssd[krb5_child[2765
> [sss_child_krb5_trace_cb] (0x4000): [2765] 1501135285.849256: Sending
> initial UDP request to dgram 10.3.200.11:88
>
> (This is the last message from PID 2765, so it was probably killed)
>
> If the servers are reachable you can just increase the krb5_child timeout
> in sssd.conf..
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org