Re: [Freeipa-users] Kerberos Clock Skew too great

[Robbie Harwood]

Rakesh Rajasekharan  writes:

> There were about 1500 hosts that were alerting for "clock skew" and the
> issue went away only after I did a resync using ntpdate on all those hosts

Great, glad it's fixed!  Are these VMs?  If not, you may wish to
(re?)configure automatic syncing.

> Is it possible that so many higher number of minor offsets adds up and
> causes it. Coz from the individual offset it looks much below the 5min limit

Not as such, if I understand you correctly?  This should only be a
problem between any two machines that need to communicate (including the
freeipa KDC).

> Or, is there a way to tell whats the offset limit its actually looking for.

5 minutes almost certainly.  The parameter to configure it is
"clockskew" in the config files, but I don't think IPA touches that.

Hope that helps,
--Robbie


signature.asc
Description: PGP signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] disable inactive accounts and delete old accounts

[Giger, Justean]

I should add that I do not have the "disable last success" option enabled for 
the IPA server
Justean

From: Justean Giger >
Date: Friday, January 6, 2017 at 9:10 AM
To: "freeipa-users@redhat.com" 
>
Subject: disable inactive accounts and delete old accounts

I am trying to use the krblastsuccessfulauth attribute to detect accounts that 
have been inactive for >90 days as per this post: 
https://www.redhat.com/archives/freeipa-users/2015-March/msg00052.html
I need to be able to disable these accounts at 90 days then delete them after 
180 days.
However, I find most of my users do not have the krblastsuccessfulauth 
attribute populated. This is not because their accounts have never been used as 
I see they do have valid passwords which expire in the future so they had to 
login at least once (not necessarily with Kerberos though). Is there another 
attribute we can/should use for this?

Justean
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] documentation or example of using S42U for NFS

[Charles Hedrick]

Various documentation suggests that it is possible for Gssproxy to get tickets 
for users who need to use NFS. This is a possible way to handle things like 
cron jobs.

However while a gssproxy.conf example is given, there’s no sign of what needs 
to be done in freeipa to authorize it. I tried following instructions for LDAP 
access, but it doesn’t work. NFS seems to use a different, two-stage method for 
getting credentials, so that’s not a surprise. There are, not surprisingly, no 
useful error messages even with logging turned all the way up.


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIpa client can't execute any command

[Petr Vobornik]

On 01/09/2017 02:56 PM, Андрей Ривкин wrote:
> Hello everyone!
> 
> I'm new to FreeIpa, so if my question is very simple just point me to the 
> documentation.
> 
> I've installed FreeIpa on host demo3.xxx.com .
> Then registred some other host demo5.xxx.com . I've 
> used 
> ipa add host command.
> Then installed ipa-client and ipa-admin-tools demo5.
> Checked that they worked and were able to execute commands like kinit and ipa 
> host-find.
> 
> On the host demo3 I've restarted service ipa (service ipa restart).
> Now I'm able to execute  ipa host-find on demo3, but not able to execute this 
> command on demo3.
> I've done kinit by 'someadmin'.
> All ipa commands not working:
> 
> 
> [root@demo5 ~]# ipa -v -d
> ipa: DEBUG: Starting external process
> ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:somead...@xxx.com 
> 
> ipa: DEBUG: Process finished, return code=1
> ipa: DEBUG: stdout=
> ipa: DEBUG: stderr=keyctl_search: Required key not available
> 
> ipa: DEBUG: failed to find session_cookie in persistent storage for principal 
> 'somead...@xxx.com '
> ipa: INFO: trying https://demo3.xxx.com/ipa/json
> ipa: DEBUG: Created connection context.rpcclient_41215888
> ipa: INFO: Forwarding 'schema' to json server 'https://demo3.xxx.com/ipa/json'
> ipa: DEBUG: Destroyed connection context.rpcclient_41215888
> ipa: ERROR: Service 'h...@demo3.xxx.com ' not 
> found 
> in Kerberos database
> 
> 
> It looks like my client is not connected to my server.
> Any ideas how to debug this situation?
> 
> P.S. Hosts - Centos 7. DNS on demo3.
> 
> Regards,
> Andrey
> 


Does following sequence work the same way on both demo3 and demo5?

 $ kdestroy -A
 $ kinit someadmin
 $ kvno HTTP/demo3.xxx.com

Does `ipactl status` show that all services are running fine?

-- 
Petr Vobornik

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SLAPD stops answering

[Troels Hansen]

- On Jan 9, 2017, at 3:37 PM, Adam Bishop adam.bis...@jisc.ac.uk wrote:

> If you attach strace to the slapd process, do you see repeated (failing) calls
> to getpeername()?
> 


Actually, just tried attaching a running dirsrv (which responds to requests): 
This also spawns lots of failing calls to getpeername:

getpeername(10, 0x7ffe7c586ea0, [112])  = -1 ENOTCONN (Transport endpoint is 
not connected)
clock_gettime(CLOCK_MONOTONIC, {2443617, 480040038}) = 0
poll([{fd=60, events=POLLIN}, {fd=9, events=POLLIN}, {fd=10, events=POLLIN}, 
{fd=11, events=POLLIN}, {fd=112, events=POLLIN}, {fd=72, events=POLLIN}, 
{fd=122, events=POLLIN}, {fd=117, events=POLLIN}, {fd=116, events=POLLIN}, 
{fd=71, events=POLLIN}, {fd=118, events=POLLIN}, {fd=68, events=POLLIN}, 
{fd=88, events=POLLIN}, {fd=86, events=POLLIN}, {fd=85, events=POLLIN}, {fd=84, 
events=POLLIN}, {fd=83, events=POLLIN}, {fd=82, events=POLLIN}, {fd=81, 
events=POLLIN}, {fd=78, events=POLLIN}, {fd=77, events=POLLIN}, {fd=73, 
events=POLLIN}, {fd=70, events=POLLIN}, {fd=67, events=POLLIN}], 24, 250) = 0 
(Timeout)
getpeername(10, 0x7ffe7c586ea0, [112])  = -1 ENOTCONN (Transport endpoint is 
not connected)
clock_gettime(CLOCK_MONOTONIC, {2443617, 73559}) = 0
poll([{fd=60, events=POLLIN}, {fd=9, events=POLLIN}, {fd=10, events=POLLIN}, 
{fd=11, events=POLLIN}, {fd=112, events=POLLIN}, {fd=72, events=POLLIN}, 
{fd=122, events=POLLIN}, {fd=117, events=POLLIN}, {fd=116, events=POLLIN}, 
{fd=71, events=POLLIN}, {fd=118, events=POLLIN}, {fd=68, events=POLLIN}, 
{fd=88, events=POLLIN}, {fd=86, events=POLLIN}, {fd=85, events=POLLIN}, {fd=84, 
events=POLLIN}, {fd=83, events=POLLIN}, {fd=82, events=POLLIN}, {fd=81, 
events=POLLIN}, {fd=78, events=POLLIN}, {fd=77, events=POLLIN}, {fd=73, 
events=POLLIN}, {fd=70, events=POLLIN}, {fd=67, events=POLLIN}], 24, 250) = 0 
(Timeout)
getpeername(10, 0x7ffe7c586ea0, [112])  = -1 ENOTCONN (Transport endpoint is 
not connected)
clock_gettime(CLOCK_MONOTONIC, {2443617, 986870733}) = 0 

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Getting error "Permission denied (publickey, gssapi-with-mic, password)" when running below ssh command

[Robert Story]

On Mon, 9 Jan 2017 10:55:05 +0100 Sumit wrote:
SB> There are older reports that a similar audit message was triggered by
SB> wrong SELinux labels on $HOME/.ssh and the files within. Although none
SB> of the typical files in this directory are needed by GSSAPI
SB> authentication it might worth to check. Does authentication work if you
SB> temporally disable SELinux by calling 'setenforce 0' as root on the
SB> command line?

Or instead of disabling, fix the labels

  restorecon -rv ~/.ssh

With -v restorecon will report if it changed any labels.

or check for actual denials

  grep avc /var/log/audit/audit.log | grep ssh



Robert

-- 
Senior Software Engineer @ Parsons


pgpjym51Kq_KZ.pgp
Description: OpenPGP digital signature
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sshd[22490]: Failed password for invalid user

[Sumit Bose]

On Mon, Jan 09, 2017 at 11:21:00AM +0100, rajat gupta wrote:
> Hi,
> 
> Error message is changed today. but same some are able to login but most of
> the user are not. Please find the below logs form ipa2 server.
> 
> /var/log/secure
> 
> Jan  9 11:02:59 ilt-gif-ipa02 sshd[18942]: pam_sss(sshd:auth):
> authentication failure; logname= uid=0 euid=0 tty=ssh ruser=
> rhost=x.x.x.x.x user=et33015
> Jan  9 11:02:59 ilt-gif-ipa02 sshd[18942]: pam_sss(sshd:auth): received for
> user et33015: 6 (Permission denied)
> Jan  9 11:02:59 ilt-gif-ipa02 sshd[18940]: error: PAM: Authentication
> failure for et33015 from x.x.x.x.x
> 
> =
> 
...
> (Mon Jan  9 11:02:59 2017) [sssd[be[ipa.preprod.local]]] [dp_req_done]
> (0x0400): DP Request [PAM Preauth #1074]: Request handler finished [0]:
> Success
> (Mon Jan  9 11:02:59 2017) [sssd[be[ipa.preprod.local]]] [_dp_req_recv]
> (0x0400): DP Request [PAM Preauth #1074]: Receiving request data.
> (Mon Jan  9 11:02:59 2017) [sssd[be[ipa.preprod.local]]]
> [dp_req_destructor] (0x0400): DP Request [PAM Preauth #1074]: Request
> removed.
> (Mon Jan  9 11:02:59 2017) [sssd[be[ipa.preprod.local]]]
> [dp_req_destructor] (0x0400): Number of active DP request: 0
> (Mon Jan  9 11:02:59 2017) [sssd[be[ipa.preprod.local]]] [dp_pam_reply]
> (0x1000): DP Request [PAM Preauth #1074]: Sending result [4][
> corp.corpcommon.com]
> (Mon Jan  9 11:02:59 2017) [sssd[be[ipa.preprod.local]]]
> [child_sig_handler] (0x1000): Waiting for child [18952].
> (Mon Jan  9 11:02:59 2017) [sssd[be[ipa.preprod.local]]]
> [child_sig_handler] (0x0100): child [18952] finished successfully.

Can you add the messages that follows here as well and the related
messages from krb5_child.log?

bye,
Sumit

> 
> 
> 
> On Mon, Jan 9, 2017 at 9:48 AM, rajat gupta  wrote:
> 
> > few user are able to login. ipa ad-trust setup.
> >
> > ==
> > Jan  6 10:48:36 ilt-gif-ipa02 sshd[22490]: reverse mapping checking
> > getaddrinfo for ilp-noatun.man.cosng.net [146.213.128.135] failed -
> > POSSIBLE BREAK-IN ATTEMPT!
> > Jan  6 10:48:48 ilt-gif-ipa02 sshd[22490]: Invalid user et33015 from
> > x.x.x.x
> > Jan  6 10:48:48 ilt-gif-ipa02 sshd[22490]: input_userauth_request: invalid
> > user et33015 [preauth]
> > Jan  6 10:48:48 ilt-gif-ipa02 sshd[22490]: error: PAM: User not known to
> > the underlying authentication module for illegal user et33015 from x.x.x.x
> > Jan  6 10:48:48 ilt-gif-ipa02 sshd[22490]: Failed keyboard-interactive/pam
> > for invalid user et33015 from x.x.x.x port 51270 ssh2
> > Jan  6 10:48:56 ilt-gif-ipa02 sshd[22490]: Failed password for invalid
> > user et33015 from 146.213.128.135 port 51270 ssh2
> > Jan  6 10:49:00 ilt-gif-ipa02 sshd[22490]: Failed password for invalid
> > user et33015 from 146.213.128.135 port 51270 ssh2
> > Jan  6 10:49:02 ilt-gif-ipa02 sshd[22490]: Failed password for invalid
> > user et33015 from 146.213.128.135 port 51270 ssh2
> > Jan  6 10:49:32 ilt-gif-ipa02 sshd[22490]: Connection closed by x.x.x.x
> > [preauth]
> > 
> >
> > 
> > (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
> > [get_server_status] (0x1000): Status of server
> > 'ilt-gif-ipa01.ipa.preprod.local' is 'working'
> > (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]] [get_port_status]
> > (0x1000): Port status of port 0 for server 'ilt-gif-ipa01.ipa.preprod.local'
> > is 'not working'
> > (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
> > [fo_resolve_service_send] (0x0020): No available servers for service 'IPA'
> > (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
> > [be_resolve_server_done] (0x1000): Server resolution failed: [5]:
> > Input/output error
> > (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
> > [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5
> > [Input/output error])
> > (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]] [be_mark_offline]
> > (0x2000): Going offline!
> > (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]] [be_mark_offline]
> > (0x2000): Initialize check_if_online_ptask.
> > (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]] [be_ptask_create]
> > (0x0400): Periodic task [Check if online (periodic)] was created
> > (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
> > [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling
> > task 72 seconds from now [1483696200]
> > (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
> > [be_run_offline_cb] (0x0080): Going offline. Running callbacks
> >
> > =
> >
> > cat /etc/sssd/sssd.conf
> > [domain/ipa.preprod.local]
> >
> > cache_credentials = True
> > krb5_store_password_if_offline = True
> > ipa_domain = ipa.preprod.local
> > id_provider = ipa
> > auth_provider = ipa
> > access_provider = ipa
> > ipa_hostname = ilt-gif-ipa02.ipa.preprod.local
> > chpass_provider = ipa
> > ipa_server = _srv_, 

Re: [Freeipa-users] SLAPD stops answering

[Adam Bishop]

On 9 Jan 2017, at 13:06, Troels Hansen  wrote:
> Anyone with some thoughts about this, other that "Just upgrade".

This sounds similar to the behaviour I'm seeing on my standalone instance; 
though I don't have anything in the error log:
  https://www.redhat.com/archives/freeipa-users/2017-January/msg00162.html

If you attach strace to the slapd process, do you see repeated (failing) calls 
to getpeername()?

Regards,

Adam Bishop

  gpg: E75B 1F92 6407 DFDF 9F1C  BF10 C993 2504 6609 D460

jisc.ac.uk

Jisc is a registered charity (number 1149740) and a company limited by 
guarantee which is registered in England under Company No. 5747339, VAT No. GB 
197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, 
BS2 0JA. T 0203 697 5800.

Jisc Services Limited is a wholly owned Jisc subsidiary and a company limited 
by guarantee which is registered in England under company number 2881024, VAT 
number GB 197 0632 86. The registered office is: One Castle Park, Tower Hill, 
Bristol BS2 0JA. T 0203 697 5800.  


-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] FreeIpa client can't execute any command

[Андрей Ривкин]

Hello everyone!

I'm new to FreeIpa, so if my question is very simple just point me to the
documentation.

I've installed FreeIpa on host demo3.xxx.com.
Then registred some other host demo5.xxx.com. I've used ipa add host
command.
Then installed ipa-client and ipa-admin-tools demo5.
Checked that they worked and were able to execute commands like kinit and
ipa host-find.

On the host demo3 I've restarted service ipa (service ipa restart).
Now I'm able to execute  ipa host-find on demo3, but not able to execute
this command on demo3.
I've done kinit by 'someadmin'.
All ipa commands not working:


[root@demo5 ~]# ipa -v -d
ipa: DEBUG: Starting external process
ipa: DEBUG: args=keyctl search @s user ipa_session_cookie:somead...@xxx.com
ipa: DEBUG: Process finished, return code=1
ipa: DEBUG: stdout=
ipa: DEBUG: stderr=keyctl_search: Required key not available

ipa: DEBUG: failed to find session_cookie in persistent storage for
principal 'somead...@xxx.com'
ipa: INFO: trying https://demo3.xxx.com/ipa/json
ipa: DEBUG: Created connection context.rpcclient_41215888
ipa: INFO: Forwarding 'schema' to json server '
https://demo3.xxx.com/ipa/json'
ipa: DEBUG: Destroyed connection context.rpcclient_41215888
ipa: ERROR: Service 'h...@demo3.xxx.com' not found in Kerberos database


It looks like my client is not connected to my server.
Any ideas how to debug this situation?

P.S. Hosts - Centos 7. DNS on demo3.

Regards,
Andrey
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] SLAPD stops answering

[Ludwig Krispenz]

Hi,

there seem to be to issues here, maybe related: a hanging slapd process 
and the retro CL errors.


If the slapd process is not responding can we get a pstack or gdb 
backtrace (http://www.port389.org/docs/389ds/FAQ/faq.html#debug_crashes) 
of the process ?
About the Retro CL messages, is it always the same changenumber which 
is  reported ?


On 01/09/2017 02:06 PM, Troels Hansen wrote:

Hi, we have a IPA installation, which obviously needs upgrading.
Its a single server running RHEL7.1 running IPA 4.1

However, it have been running smooth untill now:

Rebooting makes everything running again, but only for a few days.

It looks like everything fails around 0:17:47 and comes up again just 
before 8, when the server is rebooted.


Jan  6 00:19:46 fbbidm01 winbindd[2965]: failed to bind to server 
ldapi://%2fvar%2frun%2fslapd-DOMAIN.LAN.socket with dn="[Anonymous 
bind]" Error: Local error

Jan  6 00:19:46 fbbidm01 winbindd[2965]: (unknown)
Jan  6 00:20:29 fbbidm01 winbindd[2965]: [2017/01/06 00:20:29.758332,  
0] ipa_sam.c:4128(bind_callback_cleanup)


Looking at the SLAPD logs also reveals it stopped answering:

[06/Jan/2017:00:17:47 +0100] conn=40702 op=62 SRCH 
base="cn=radius_aura_admin,cn=groups,cn=accounts,dc=domain,dc=lan" 
scope=0 filter="(objectClass=*)" attrs="cn"
[06/Jan/2017:00:17:47 +0100] conn=40702 op=62 RESULT err=0 tag=101 
nentries=1 etime=0
[06/Jan/2017:00:17:47 +0100] conn=40702 op=63 SRCH 
base="cn=radius_users,cn=groups,cn=accounts,dc=domain,dc=lan" scope=0 
filter="(objectClass=*)" attrs="cn"
[06/Jan/2017:00:17:47 +0100] conn=40702 op=63 RESULT err=0 tag=101 
nentries=1 etime=0
[06/Jan/2017:00:17:47 +0100] conn=40702 op=64 SRCH 
base="cn=system_radius_users,cn=groups,cn=accounts,dc=domain,dc=lan" 
scope=0 filter="(objectClass=*)" attrs="cn"
[06/Jan/2017:00:17:47 +0100] conn=40702 op=64 RESULT err=0 tag=101 
nentries=1 etime=0
[06/Jan/2017:00:17:48 +0100] conn=40702 op=65 SRCH 
base="cn=accounts,dc=domain,dc=lan" scope=2 
filter="(uid=sys_prov_aura)" attrs=ALL
[06/Jan/2017:00:17:48 +0100] conn=40702 op=65 RESULT err=0 tag=101 
nentries=1 etime=0
[06/Jan/2017:00:17:48 +0100] conn=40702 op=66 BIND 
dn="uid=sys_prov_aura,cn=users,cn=accounts,dc=domain,dc=lan" 
method=128 version=3
[06/Jan/2017:00:17:48 +0100] conn=40702 op=66 RESULT err=0 tag=97 
nentries=0 etime=0 
dn="uid=sys_prov_aura,cn=users,cn=accounts,dc=domain,dc=lan"
[06/Jan/2017:00:17:51 +0100] conn=40703 fd=158 slot=158 connection 
from 10.250.8.66 to 10.250.8.58
[06/Jan/2017:00:17:53 +0100] conn=40704 fd=159 slot=159 SSL connection 
from 10.250.8.37 to 10.250.8.58
[06/Jan/2017:00:18:02 +0100] conn=40705 fd=160 slot=160 SSL connection 
from 10.250.8.57 to 10.250.8.58
[06/Jan/2017:00:18:02 +0100] conn=40706 fd=161 slot=161 SSL connection 
from 10.250.20.102 to 10.250.8.58
[06/Jan/2017:00:18:03 +0100] conn=40707 fd=162 slot=162 SSL connection 
from 10.250.20.102 to 10.250.8.58
[06/Jan/2017:00:18:58 +0100] conn=40708 fd=163 slot=163 connection 
from 10.250.8.66 to 10.250.8.58
[06/Jan/2017:00:19:03 +0100] conn=40709 fd=164 slot=164 connection 
from local to /var/run/slapd-DOMAIN.LAN.socket
[06/Jan/2017:00:19:35 +0100] conn=40710 fd=165 slot=165 connection 
from 10.250.8.58 to 10.250.8.58
[06/Jan/2017:00:19:35 +0100] conn=40711 fd=166 slot=166 connection 
from 10.150.27.7 to 10.250.8.58
[06/Jan/2017:00:19:43 +0100] conn=40712 fd=167 slot=167 SSL connection 
from 10.250.20.102 to 10.250.8.58
[06/Jan/2017:00:19:46 +0100] conn=40713 fd=168 slot=168 connection 
from local to /var/run/slapd-DOMAIN.LAN.socket


It looks like it just stops answering at 00:17:48

The slapd error log reveals nothing:

[06/Jan/2017:00:17:34 +0100] DSRetroclPlugin - replog: an error 
occured while adding change number 3875312, dn = 
changenumber=3875312,cn=changelog: Already exists.
[06/Jan/2017:00:17:34 +0100] retrocl-plugin - retrocl_postob: 
operation failure [68]
[06/Jan/2017:07:57:21 +0100] - slapd shutting down - signaling 
operation threads - op stack size 0 max work q size 735 max work q 
stack size 23
[06/Jan/2017:07:57:21 +0100] - slapd shutting down - waiting for 30 
threads to terminate
[06/Jan/2017:07:58:02 +0100] SSL Initialization - Configured SSL 
version range: min: TLS1.0, max: TLS1.2


However, see a gazillion of these lines in the error log:

DSRetroclPlugin - replog: an error occured while adding change number 
3875312, dn = changenumber=3875312,cn=changelog: Already exists.


Anyone with some thoughts about this, other that "Just upgrade".

--

Med venlig hilsen

*Troels Hansen*

Systemkonsulent

Casalogic A/S

T  (+45) 70 20 10 63

M (+45) 22 43 71 57

 
 
Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, 
Sophos og meget mere.





--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael 

Re: [Freeipa-users] freeipa 4.4.0 and Ubuntu 14.04

[Youenn PIOLET]

Hey there,

I got the same issue after upgrading my servers to 4.4.0
The problem comes from duplicate entries in :
cn=permissions,cn=pbac,dc=example,dc=com

I think FreeIPA upgrade fails to create ACL on pbac specific entries,
resulting in a conflict entry creation.

The problem is that SSSD on Ubuntu 14.04 is crashing when reading pbac
where cn contains symbol "+".
You should check if you got these conflict entries in
cn=permissions,cn=pbac,dc=example,dc=com and remove them.

Ubuntu authentication was working for me directly after the suppression.

Regards,

--
Youenn Piolet
piole...@gmail.com


2017-01-09 8:56 GMT+01:00 Jakub Hrozek :

> On Fri, Jan 06, 2017 at 11:48:07AM -0500, Andy Brittingham wrote:
> > Sorry for the delay, was doing some troubleshooting.
> >
> > Here is what I know now:
> >
> > The problem is on Ubuntu hosts using older sssd versions 1.11.8 (Ubuntu
> > 14.04).
> >
> > SSSD versions 1.13.4 (Ubuntu 16.04) and 1.13.3 (CentOS 6.8) both work.
> >
> > Users in the admin group can't log into these hosts.
> >
> > I created a newadmins group and assigned a new user to it. When I add the
> > "User Administrator" role the new user can't log into the hosts with
> older
> > sssd.
> >
> > As soon as I delete the "User Administrator" role, new user has access
> > again.
>
> So is it a role membership or a group membership that makes the
> difference?
>
> >
> > I've pasted the last bit of logs from a sssd_domain log below. I'd be
> happy
> > to forward the entire log, or additional logs if they will be helpful.
>
> The log only captures a user lookup, not a login, sorry..
>
> (This might be expected if you log in e.g. with an SSH key, in which
> case journald should be the first thing to look at at least to poinpoint
> which piece denied access..)
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] SLAPD stops answering

[Troels Hansen]

Hi, we have a IPA installation, which obviously needs upgrading. 
Its a single server running RHEL7.1 running IPA 4.1 

However, it have been running smooth untill now: 

Rebooting makes everything running again, but only for a few days. 

It looks like everything fails around 0:17:47 and comes up again just before 8, 
when the server is rebooted. 

Jan 6 00:19:46 fbbidm01 winbindd[2965]: failed to bind to server 
ldapi://%2fvar%2frun%2fslapd-DOMAIN.LAN.socket with dn="[Anonymous bind]" 
Error: Local error 
Jan 6 00:19:46 fbbidm01 winbindd[2965]: (unknown) 
Jan 6 00:20:29 fbbidm01 winbindd[2965]: [2017/01/06 00:20:29.758332, 0] 
ipa_sam.c:4128(bind_callback_cleanup) 

Looking at the SLAPD logs also reveals it stopped answering: 

[06/Jan/2017:00:17:47 +0100] conn=40702 op=62 SRCH 
base="cn=radius_aura_admin,cn=groups,cn=accounts,dc=domain,dc=lan" scope=0 
filter="(objectClass=*)" attrs="cn" 
[06/Jan/2017:00:17:47 +0100] conn=40702 op=62 RESULT err=0 tag=101 nentries=1 
etime=0 
[06/Jan/2017:00:17:47 +0100] conn=40702 op=63 SRCH 
base="cn=radius_users,cn=groups,cn=accounts,dc=domain,dc=lan" scope=0 
filter="(objectClass=*)" attrs="cn" 
[06/Jan/2017:00:17:47 +0100] conn=40702 op=63 RESULT err=0 tag=101 nentries=1 
etime=0 
[06/Jan/2017:00:17:47 +0100] conn=40702 op=64 SRCH 
base="cn=system_radius_users,cn=groups,cn=accounts,dc=domain,dc=lan" scope=0 
filter="(objectClass=*)" attrs="cn" 
[06/Jan/2017:00:17:47 +0100] conn=40702 op=64 RESULT err=0 tag=101 nentries=1 
etime=0 
[06/Jan/2017:00:17:48 +0100] conn=40702 op=65 SRCH 
base="cn=accounts,dc=domain,dc=lan" scope=2 filter="(uid=sys_prov_aura)" 
attrs=ALL 
[06/Jan/2017:00:17:48 +0100] conn=40702 op=65 RESULT err=0 tag=101 nentries=1 
etime=0 
[06/Jan/2017:00:17:48 +0100] conn=40702 op=66 BIND 
dn="uid=sys_prov_aura,cn=users,cn=accounts,dc=domain,dc=lan" method=128 
version=3 
[06/Jan/2017:00:17:48 +0100] conn=40702 op=66 RESULT err=0 tag=97 nentries=0 
etime=0 dn="uid=sys_prov_aura,cn=users,cn=accounts,dc=domain,dc=lan" 
[06/Jan/2017:00:17:51 +0100] conn=40703 fd=158 slot=158 connection from 
10.250.8.66 to 10.250.8.58 
[06/Jan/2017:00:17:53 +0100] conn=40704 fd=159 slot=159 SSL connection from 
10.250.8.37 to 10.250.8.58 
[06/Jan/2017:00:18:02 +0100] conn=40705 fd=160 slot=160 SSL connection from 
10.250.8.57 to 10.250.8.58 
[06/Jan/2017:00:18:02 +0100] conn=40706 fd=161 slot=161 SSL connection from 
10.250.20.102 to 10.250.8.58 
[06/Jan/2017:00:18:03 +0100] conn=40707 fd=162 slot=162 SSL connection from 
10.250.20.102 to 10.250.8.58 
[06/Jan/2017:00:18:58 +0100] conn=40708 fd=163 slot=163 connection from 
10.250.8.66 to 10.250.8.58 
[06/Jan/2017:00:19:03 +0100] conn=40709 fd=164 slot=164 connection from local 
to /var/run/slapd-DOMAIN.LAN.socket 
[06/Jan/2017:00:19:35 +0100] conn=40710 fd=165 slot=165 connection from 
10.250.8.58 to 10.250.8.58 
[06/Jan/2017:00:19:35 +0100] conn=40711 fd=166 slot=166 connection from 
10.150.27.7 to 10.250.8.58 
[06/Jan/2017:00:19:43 +0100] conn=40712 fd=167 slot=167 SSL connection from 
10.250.20.102 to 10.250.8.58 
[06/Jan/2017:00:19:46 +0100] conn=40713 fd=168 slot=168 connection from local 
to /var/run/slapd-DOMAIN.LAN.socket 

It looks like it just stops answering at 00:17:48 

The slapd error log reveals nothing: 

[06/Jan/2017:00:17:34 +0100] DSRetroclPlugin - replog: an error occured while 
adding change number 3875312, dn = changenumber=3875312,cn=changelog: Already 
exists. 
[06/Jan/2017:00:17:34 +0100] retrocl-plugin - retrocl_postob: operation failure 
[68] 
[06/Jan/2017:07:57:21 +0100] - slapd shutting down - signaling operation 
threads - op stack size 0 max work q size 735 max work q stack size 23 
[06/Jan/2017:07:57:21 +0100] - slapd shutting down - waiting for 30 threads to 
terminate 
[06/Jan/2017:07:58:02 +0100] SSL Initialization - Configured SSL version range: 
min: TLS1.0, max: TLS1.2 

However, see a gazillion of these lines in the error log: 

DSRetroclPlugin - replog: an error occured while adding change number 3875312, 
dn = changenumber=3875312,cn=changelog: Already exists. 

Anyone with some thoughts about this, other that "Just upgrade". 

-- 


Med venlig hilsen 

Troels Hansen 

Systemkonsulent 

Casalogic A/S 


T (+45) 70 20 10 63 

M (+45) 22 43 71 57 

Red Hat, SUSE, VMware, Citrix, Novell, Yellowfin BI, EnterpriseDB, Sophos og 
meget mere. 
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[Lukas Slebodnik]

On (09/01/17 12:44), James Harrison wrote:
>All,debian 1.8.19-1 doesnt work, but Ubuntu 1.8.12-1ubuntu3 does.
>
Could you provide sudo logs with 1.8.19-1
https://fedorahosted.org/sssd/wiki/HOWTO_Troubleshoot_SUDO

sssd log files will be helpfull as well.


LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] ipa replica installation help

[Florence Blanc-Renaud]

On 01/09/2017 01:27 PM, Ben .T.George wrote:

Hi LIst,

is there anyone faces/fixed this issue?

Regards,
BEn


Hi Ben,

the directory server fails to restart on the replica. Are there any 
specific error message in /var/log/dirsrv/slapd-$DOMAIN/errors and 
access log files? If you are hitting ticket 6575 [1], there should be an 
error about a missing Server-Cert certificate (similar to: "Can't find 
certificate Server-Cert"), and no Server-Cert in /etc/dirsrv/slap-$DOMAIN.


Otherwise we need to figure out what causes the dirsrv startup error.

Flo

[1] https://fedorahosted.org/freeipa/ticket/6575


On Sun, Jan 8, 2017 at 7:03 AM, Ben .T.George > wrote:

HI List,

how can i solve this? is this a bug ,normal behavior or any missing
configuration from my end,

Till now i didn't get ant clue on this.

Regards
Ben

On Thu, Jan 5, 2017 at 1:21 PM, Fraser Tweedale > wrote:

On Thu, Jan 05, 2017 at 01:08:58PM +0300, Ben .T.George wrote:
> HI
>
> there is no filrewall running on both servers,
>
> [root@zkwipamstr01 ~]# systemctl status firewalld
> ● firewalld.service - firewalld - dynamic firewall daemon
>Loaded: loaded (/usr/lib/systemd/system/firewalld.service; 
disabled;
> vendor preset: enabled)
>Active: inactive (dead)
>  Docs: man:firewalld(1)
>
> [root@zkwipamstr01 ~]# sestatus
> SELinux status: disabled
>
OK, very well.  And actually, forget about my idea about connecting
to port 8009 from client - that is not what happens at all.  It is
the end of day for me and my brain checked out :/

I shall continue analysis of your problem tomorrow.

Thanks,
Fraser

>
> On Thu, Jan 5, 2017 at 1:05 PM, Fraser Tweedale
> wrote:
>
> > On Thu, Jan 05, 2017 at 12:43:47PM +0300, Ben .T.George wrote:
> > > HI,
> > >
> > > on master server and replica server, i have enabled ipv6
> > >
> > > below on master server
> > >
> > > [root@zkwipamstr01 ~]# ip addr | grep inet6
> > >
> > > inet6 fe80::250:56ff:fea0:3857/64 scope link
> > >
> > > [root@zkwipamstr01 ~]# systemctl restart
pki-tomcatd@pki-tomcat
> > > [root@zkwipamstr01 ~]# netstat -tunap | grep 8009
> > > tcp6   0  0 ::1:8009:::*
> > LISTEN
> > >  12692/java
> > >
> > >
> > > after that 8009 is listening on master server.
> > >
> > > on replica side uninstalled ipa and tried to enrolled
again. Do i need to
> > > enable any service replica side?
> > >
> > > [28/44]: restarting directory server
> > > ipa : CRITICAL Failed to restart the directory
server (Command
> > > '/bin/systemctl restart dirsrv@KW-EXAMPLE-COM.service'
returned non-zero
> > > exit status 1). See the installation log for details.
> > >   [29/44]: setting up initial replication
> > >   [error] error: [Errno 111] Connection refused
> > > Your system may be partly configured.
> > > Run /usr/sbin/ipa-server-install --uninstall to clean up.
> > >
> > > ipa.ipapython.install.cli.install_tool(Replica): ERROR
[Errno 111]
> > > Connection refused
> > > ipa.ipapython.install.cli.install_tool(Replica): ERRORThe
> > > ipa-replica-install command failed. See
/var/log/ipareplica-install.log
> > for
> > > more information
> > > [root@zkwiparepa01 ~]# systemctl restart
pki-tomcatd@pki-tomcat
> > > Job for pki-tomcatd@pki-tomcat.service failed because the
control
> > process
> > > exited with error code. See "systemctl status
> > pki-tomcatd@pki-tomcat.service"
> > > and "journalctl -xe" for details.
> > >
> > > Still same error.
> > >
> > > is this service restart pki-tomcatd@pki-tomcat only
applicable on master
> > > server?
> > >
> > Yes, because no CA has been created on replica (yet).
> >
> > Can you confirm that your firewall (if any/enabled) on master is
> > letting the traffic from client/replica through to :8009?
> > Executing: ``nc -v $MASTER_IP 8009`` from the client machine
> > suffices to check.
> >
> > Thanks,
> > Fraser
> >
> > > Regards,
> > > Ben
> > >
> > >
> > > On Thu, Jan 5, 2017 at 11:12 AM, Petr Vobornik
>
   

[Freeipa-users] FreeIPA, Duo Security integration

[Oucema Bellagha]

Hi,
As of now, we have FreeIPA with OTP working perfectly.  Now, I am looking at 
possibly integrating Duo security instead of FreeIPA's 2FA.  I am concerned 
about how it will fit in with FreeIPA... Has anyone else tried this before?  If 
so, are there any pitfalls or problems you have encountered or any general 
advise?

Cheers,

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[James Harrison]

All,debian 1.8.19-1 doesnt work, but Ubuntu 1.8.12-1ubuntu3 does.

James
  From: Lukas Slebodnik 
 To: James Harrison  
Cc: "freeipa-users@redhat.com" 
 Sent: Saturday, 7 January 2017, 15:34
 Subject: Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd 
version 1.13.4-1ubuntu1.1
   
On (06/01/17 17:15), James Harrison wrote:
>Any ideas?
>      From: James Harrison 
> To: "freeipa-users@redhat.com"  
> Sent: Thursday, 5 January 2017, 13:36
> Subject: FreeIPA sudo not working on ububtu xenial sssd version 
> 1.13.4-1ubuntu1.1
>  
>Hi all,I having problems with a FreeIPA client running Ububtu Xenial.
>I can authenticate OK, I get a kerberos ticket, but cannot run sudo.
>I get 1 rule returned, which I expect.
>Many thanks,James Harrison
>
>
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning 
>info for user [x_james.harri...@domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x0400): 
>Retrieving rules for [x_james.harrison] from [domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
>"ltdb_callback": 0x1c11d70
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
>(0x0200): Searching sysdb with 
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*))(&(dataExpireTimestamp<=1483618197)))]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to 
>get sudo rules from cache
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
>(0x0200): Searching sysdb with 
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*)))]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting 
>rules with higher-wins logic
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] 
>(0x0400): Returning 1 rules for [x_james.harri...@domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle 
>timer re-set for client [0x1c0e770][18]
>
Yes, 1 rule was returned for user x_james.harrison.
Can you see something in output of "sudo -l"


>==> sssd/sssd_pam.log <==
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [get_client_cred] (0x4000): Client 
>creds: euid[0] egid[1082600012] pid[5470].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [accept_fd_handler] (0x0400): Client 
>connected!
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): 
>Received client version [3].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered 
>version [3].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>
>==> auth.log <==
>Jan  5 12:10:17 pul-lp-sql-00 sudo: pam_unix(sudo:auth): authentication 
>failure; logname=x_james.harrison uid=1082600012 euid=0 tty=/dev/pts/1 
>ruser=x_james.harrison rhost=  user=x_james.harrison
>
I do not understand a reason why there is a failure in auth.log;
because there isn't sssd_pam.log @see above.

>==> sssd/sssd_pam.log <==
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_cmd_authenticate] (0x0100): 
>entering pam_cmd_authenticate
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): 
>name 'x_james.harrison' matched without domain, user is x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): command: 
>SSS_PAM_AUTHENTICATE
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: not 
>set
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): user: 
>x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sudo
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: 
>/dev/pts/1
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: 
>x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: not 
>set
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok 
>type: 1
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok 
>type: 0
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 0
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 5470
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): logon 

Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd version 1.13.4-1ubuntu1.1

[James Harrison]

All,1.8.19-1 from Debian does not appear to work too.
James


  From: Lukas Slebodnik 
 To: James Harrison  
Cc: "freeipa-users@redhat.com" 
 Sent: Saturday, 7 January 2017, 15:34
 Subject: Re: [Freeipa-users] FreeIPA sudo not working on ububtu xenial sssd 
version 1.13.4-1ubuntu1.1
   
On (06/01/17 17:15), James Harrison wrote:
>Any ideas?
>      From: James Harrison 
> To: "freeipa-users@redhat.com"  
> Sent: Thursday, 5 January 2017, 13:36
> Subject: FreeIPA sudo not working on ububtu xenial sssd version 
> 1.13.4-1ubuntu1.1
>  
>Hi all,I having problems with a FreeIPA client running Ububtu Xenial.
>I can authenticate OK, I get a kerberos ticket, but cannot run sudo.
>I get 1 rule returned, which I expect.
>Many thanks,James Harrison
>
>
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_user] (0x0400): Returning 
>info for user [x_james.harri...@domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x0400): 
>Retrieving rules for [x_james.harrison] from [domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [ldb] (0x4000): Added timed event 
>"ltdb_callback": 0x1c11d70
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
>(0x0200): Searching sysdb with 
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*))(&(dataExpireTimestamp<=1483618197)))]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_rules] (0x2000): About to 
>get sudo rules from cache
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] 
>(0x0200): Searching sysdb with 
>[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=x_james.harrison)(sudoUser=#1082600012)(sudoUser=%admins)(sudoUser=%ipausers)(sudoUser=%x_james.harrison)(sudoUser=+*)))]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting 
>rules with higher-wins logic
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] 
>(0x0400): Returning 1 rules for [x_james.harri...@domain.com]
>(Thu Jan  5 12:09:57 2017) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle 
>timer re-set for client [0x1c0e770][18]
>
Yes, 1 rule was returned for user x_james.harrison.
Can you see something in output of "sudo -l"


>==> sssd/sssd_pam.log <==
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [get_client_cred] (0x4000): Client 
>creds: euid[0] egid[1082600012] pid[5470].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [accept_fd_handler] (0x0400): Client 
>connected!
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): 
>Received client version [3].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): Offered 
>version [3].
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>
>==> auth.log <==
>Jan  5 12:10:17 pul-lp-sql-00 sudo: pam_unix(sudo:auth): authentication 
>failure; logname=x_james.harrison uid=1082600012 euid=0 tty=/dev/pts/1 
>ruser=x_james.harrison rhost=  user=x_james.harrison
>
I do not understand a reason why there is a failure in auth.log;
because there isn't sssd_pam.log @see above.

>==> sssd/sssd_pam.log <==
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer 
>re-set for client [0x2466e50][19]
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_cmd_authenticate] (0x0100): 
>entering pam_cmd_authenticate
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): 
>name 'x_james.harrison' matched without domain, user is x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): command: 
>SSS_PAM_AUTHENTICATE
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): domain: not 
>set
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): user: 
>x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): service: sudo
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: 
>/dev/pts/1
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: 
>x_james.harrison
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost: not 
>set
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok 
>type: 1
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok 
>type: 0
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 0
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 5470
>(Thu Jan  5 12:10:17 2017) [sssd[pam]] [pam_print_data] (0x0100): logon name: 

Re: [Freeipa-users] ipa_server and ipa_backup_server failover time

[Jakub Hrozek]

(please keep CC-ing the list..)

On Mon, Jan 09, 2017 at 04:39:04PM +0800, Matrix wrote:
> Sorry, i did not trigger authentication at all. Just to check sssd logs. 
> around 15 minutes later, I saw below messages shown:
> 
> (Mon Jan  9 01:46:35 2017) [sssd[be[fwmrm.net]]] [fo_set_port_status] 
> (0x0100): Marking port 0 of server 'ipa02.example.com' as 'working'
> 
> Re-check it with authentication, failover will be happened immediately. 

Yes, then that is expected, the identity lookup was probably answered from
the cache.

> 
> >> No, sorry, the timeouts for switching between back up and primary
> >> servers are hardcoded.
> 
> May I know how long it will take for worst case? 

Seems to be 30 minutes:

https://github.com/SSSD/sssd/blob/master/src/providers/data_provider_fo.c#L49

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Kerberos Clock Skew too great

[Jakub Hrozek]

On Mon, Jan 09, 2017 at 02:07:21PM +0530, Rakesh Rajasekharan wrote:
> yes on the IPA server as well.. the offset isn't that high
> 
>  remote   refid  st t when poll reach   delay   offset
> jitter
> ==
> *ip-10-10-1-150.e 132.163.4.1012 u  119  128  3770.431   -0.279
> 0.348
> 
> So, my NTP server, the ipa client and the IPA master.. all seems to not
> have a high offset or a jitter.
> 
> There were about 1500 hosts that were alerting for "clock skew" and the
> issue went away only after I did a resync using ntpdate on all those hosts
> 
> Is it possible that so many higher number of minor offsets adds up and
> causes it. Coz from the individual offset it looks much below the 5min limit
> 
> Or, is there a way to tell whats the offset limit its actually looking for.

Sorry, I'm a bit out of my depth here, the only other suggestion I have
is to try kinit with KRB5_TRACE=/dev/stderr when that happens, which
should at least dump which KDC is the client talking to (if you have
multiple masters..)

> 
> Thanks,
> Rakesh
> 
> 
> 
> On Mon, Jan 9, 2017 at 1:42 PM, Jakub Hrozek  wrote:
> 
> > On Mon, Jan 09, 2017 at 01:07:06PM +0530, Rakesh Rajasekharan wrote:
> > > Hi,
> > >
> > > I am using a Freeipa 4.2.0 server.
> > >
> > > I sometimes see, "clock skew too great" errors in /var/log/krb5kdc.log.
> > And
> > > when this happens, usually logins or new ipa-cleint-install fails.
> > >
> > > When I checked on one of the hosts for which the clock skew was reported,
> > >
> > > #> ntpq -p
> > > remote   refid  st t when poll reach   delay   offset
> > > jitter
> > > 
> > ==
> > > *ip-10-10-1-150.e 171.66.97.1262 u  869 1024  3770.4480.047
> > > 0.142
> >
> > In general, 5 minutes is OK at least. But are you sure the server is also
> > in sync or just the client against an NTP server (iow, are you sure you
> > are checking the difference between a client and the KDC as well?)
> >
> > --
> > Manage your subscription for the Freeipa-users mailing list:
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > Go to http://freeipa.org for more info on the project
> >

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Getting error "Permission denied (publickey, gssapi-with-mic, password)" when running below ssh command

[Sumit Bose]

On Sat, Jan 07, 2017 at 02:14:45AM +, Chen Lufan wrote:
> Dear Team,
> 
> I am new to freeIPA and GSS authentication so maybe someone can shed a light 
> on where the issue is when I perform below ssh?  Your help will be greatly 
> appreciated!
> 
> 
> host2$  ssh -F /home/user/config   u...@host1.example.com
> 
> 
> I got below error in audit.log in host1  :
> 
> type=CRYPTO_SESSION msg=audit(1483753488.905:727): user pid=17872 uid=0 
> auid=6974 msg='op=start direction=from-server cipher=aes128-ctr ksize=128 
> rport=36989 laddr=67.217.92.20 lport=22 id=4294967295 exe="/usr/sbin/sshd" 
> (hostname=?, addr=10.22.6.70, terminal=? res=success)'
> type=USER_ERR msg=audit(1483753489.839:728): user pid=17872 uid=0 auid=6974 
> msg='PAM: bad_ident acct="?" : exe="/usr/sbin/sshd" (hostname=10.22.6.70, 
> addr=10.22.6.70, terminal=ssh res=failed)'

There are older reports that a similar audit message was triggered by
wrong SELinux labels on $HOME/.ssh and the files within. Although none
of the typical files in this directory are needed by GSSAPI
authentication it might worth to check. Does authentication work if you
temporally disable SELinux by calling 'setenforce 0' as root on the
command line?

HTH

bye,
Sumit

> 
> 
> where
> 
> host2$ more /home/user/config
> Host *
> Protocol 2
> 
> # Options for Protocol 1 only
> #RSAAuthentication no
> #RhostsRSAAuthentication no
> 
> HostbasedAuthentication no
> PubKeyAuthentication no
> PasswordAuthentication no
> 
> GSSAPIAuthentication yes
> GSSAPIDelegateCredentials yes
> 
> PreferredAuthentications gssapi-with-mic
> 
> StrictHostKeyChecking no
> CheckHostIP no
> 
> LogLevel FATAL
> 
> UserKnownHostsFile /uhome/installer/.ssh/known_hosts
> IdentityFile /uhome/installer/.ssh/id_rsa
> 
> 
> AND on host1:
> 
> # grep -v "^#" /etc/ssh/sshd_config |grep -v "^$"
> Protocol 2
> SyslogFacility AUTHPRIV
> LogLevel INFO
> PermitRootLogin no
> PubkeyAuthentication yes
> HostbasedAuthentication no
> IgnoreRhosts yes
> PermitEmptyPasswords no
> ChallengeResponseAuthentication no
> GSSAPIAuthentication yes
> UsePAM yes
> AllowTcpForwarding no
> X11Forwarding no
> PrintMotd no
> UseDNS no
> Banner /etc/issue.net
> Subsystem   sftp/usr/libexec/openssh/sftp-server
> Ciphers aes128-ctr,aes192-ctr,aes256-ctr
> 
> host1# more krb5.conf
> 
> [libdefaults]
>   default_realm = EXAMPLE.COM
>   dns_lookup_realm = false
>   dns_lookup_kdc = false
>   ticket_lifetime = 24h
>   forwardable = yes
> 
> [realms]
>   EXAMPLE.COM = {
> kdc = auth1.iad.example.com.
> kdc = auth2.iad.example.com.
> admin_server = auth1.iad.example.com.
> 
> default_domain = example.com
> pkinit_anchors = FILE:/etc/ipa/ca.crt
> 
> auth_to_local = RULE:[2:$1;$2](.*;root)s/;root$//
> auth_to_local = RULE:[2:$1;$2](.*;admin)s/;admin$//
> auth_to_local = RULE:[1:$1@$0](.*@AD.CORP.EXAMPLE.COM)s/@.*$//
> auth_to_local = DEFAULT
> }
> 
> [domain_realm]
>   .example.com = EXAMPLE.COM
>   example.com = EXAMPLE.COM
> 
> [appdefaults]
>   pam = {
> debug = false
> ticket_lifetime = 36000
> renew_lifetime = 36000
> forwardable = true
> krb4_convert = false
>   }
> 
> 
> Thanks,
> 
> Lufan
> 
> 
> 

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] FreeIPA + /etc/named.conf

[Martin Basti]

On 06.01.2017 18:14, TomK wrote:

On 1/5/2017 2:17 PM, Martin Basti wrote:



On 05.01.2017 20:03, TomK wrote:

Hey All,

QQ.

Should the DNS forwarders be updated in /etc/named.conf? Until I
manually change /etc/named.conf, can't ping the windows AD cluster:
mds.xyz.  Nor can I get dig to resolve the SRV records (dig SRV
_ldap._tcp.mds.xyz).

sssd-ipa-1.14.0-43.el7_3.4.x86_64
ipa-client-4.4.0-14.el7.centos.x86_64

IPA command below indicates that it's set to 'first' but that's not
what's in /etc/named.conf file when I check.  Again, it works if I
change /etc/named.conf manually.



Forwarder settings has priority:

named.conf < global forwarders (ipa dnsconfig-mod) < local dns server
config (ipa dnsserver-*) < forwardzones (applied per query, not as
global forwarder)

so what is in named.conf is usually always overwritten


How did you edited the named.conf?

Does dig @192.168.0.224 SRV _ldap._tcp.mds.xyz. works?
Do you have any errors in journalctl -u named-pkcs11 ??

Martin


Thanks Martin.

Yes, with the manual update of /etc/named.conf this command works, as 
I posted earlier (It doesn't work without the manual update of 
/etc/named.conf to  forward first; ):


dig @192.168.0.224 SRV _ldap._tcp.mds.xyz.

;; ANSWER SECTION:
_ldap._tcp.mds.xyz. 3600IN  SRV 0 100 389 
winad02.mds.xyz.
_ldap._tcp.mds.xyz. 600 IN  SRV 0 100 389 
winad01.mds.xyz.


Yes I stumbled on the journalctl command but really haven't seen 
anything applicable to my scenario AFAIKT.  Nontheless, logs available 
below:


http://microdevsys.com/freeipa/named-pkcs11-working.log
http://microdevsys.com/freeipa/named-pkcs11-non-working.log
http://microdevsys.com/freeipa/named-pkcs11-working-again.log

I'm still going over them.  The only message that seamed to make sense 
was:


ignoring inherited 'forward first;' for zone '.' - did you want 
'forward only;' to override automatic empty zone


but it appears in both the working and non-working situations so isn't 
looking significant ATM and nothing I found applied to this scenario.  
Btw:


[root@idmipa01 log]# cat /etc/resolv.conf
search nix.mds.xyz mds.xyz
nameserver 127.0.0.1
You have new mail in /var/spool/mail/root
[root@idmipa01 log]#

And based on earlier chats, that's how it should stay.  Resolution of 
AD ID's does work from clients though (When I have forward first; in 
/etc/named.conf)







For me it looks like some DNSSEC validation issue, could you temporarily 
disable DNSSEC validation in /etc/named.conf on IPA server and then try 
again with forward only?


Martin

--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] sshd[22490]: Failed password for invalid user

[Sumit Bose]

On Mon, Jan 09, 2017 at 09:48:50AM +0100, rajat gupta wrote:
> few user are able to login. ipa ad-trust setup.
> 
> ==
> Jan  6 10:48:36 ilt-gif-ipa02 sshd[22490]: reverse mapping checking
> getaddrinfo for ilp-noatun.man.cosng.net [146.213.128.135] failed -
> POSSIBLE BREAK-IN ATTEMPT!
> Jan  6 10:48:48 ilt-gif-ipa02 sshd[22490]: Invalid user et33015 from x.x.x.x
> Jan  6 10:48:48 ilt-gif-ipa02 sshd[22490]: input_userauth_request: invalid
> user et33015 [preauth]
> Jan  6 10:48:48 ilt-gif-ipa02 sshd[22490]: error: PAM: User not known to
> the underlying authentication module for illegal user et33015 from x.x.x.x
> Jan  6 10:48:48 ilt-gif-ipa02 sshd[22490]: Failed keyboard-interactive/pam
> for invalid user et33015 from x.x.x.x port 51270 ssh2
> Jan  6 10:48:56 ilt-gif-ipa02 sshd[22490]: Failed password for invalid user
> et33015 from 146.213.128.135 port 51270 ssh2
> Jan  6 10:49:00 ilt-gif-ipa02 sshd[22490]: Failed password for invalid user
> et33015 from 146.213.128.135 port 51270 ssh2
> Jan  6 10:49:02 ilt-gif-ipa02 sshd[22490]: Failed password for invalid user
> et33015 from 146.213.128.135 port 51270 ssh2
> Jan  6 10:49:32 ilt-gif-ipa02 sshd[22490]: Connection closed by x.x.x.x
> [preauth]
> 
> 
> 
> (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
> [get_server_status] (0x1000): Status of server
> 'ilt-gif-ipa01.ipa.preprod.local' is 'working'
> (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]] [get_port_status]
> (0x1000): Port status of port 0 for server 'ilt-gif-ipa01.ipa.preprod.local'
> is 'not working'
> (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
> [fo_resolve_service_send] (0x0020): No available servers for service 'IPA'
> (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
> [be_resolve_server_done] (0x1000): Server resolution failed: [5]:
> Input/output error
> (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
> [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5
> [Input/output error])
> (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]] [be_mark_offline]
> (0x2000): Going offline!
> (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]] [be_mark_offline]
> (0x2000): Initialize check_if_online_ptask.
> (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]] [be_ptask_create]
> (0x0400): Periodic task [Check if online (periodic)] was created
> (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
> [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling
> task 72 seconds from now [1483696200]
> (Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
> [be_run_offline_cb] (0x0080): Going offline. Running callbacks

more data form the domain log is needed here, because it is not clear if
the system went offline before or after processing the request and why
the port is marked as not working. Please include the log data up to 5
minutes before as well.

bye,
Sumit

> 
> =
> 
> cat /etc/sssd/sssd.conf
> [domain/ipa.preprod.local]
> 
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = ipa.preprod.local
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = ilt-gif-ipa02.ipa.preprod.local
> chpass_provider = ipa
> ipa_server = _srv_, ilt-gif-ipa01.ipa.preprod.local
> ldap_tls_cacert = /etc/ipa/ca.crt
> debug_level = 9
> 
> 
> [sssd]
> default_domain_suffix = corp.corpcommon.com
> services = nss, sudo, pam, ssh
> debug_level = 9
> 
> 
> domains = ipa.preprod.local
> [nss]
> override_homedir = /home/%u
> debug_level = 9
> 
> 
> 
> [pam]
> debug_level = 9
> 
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> debug_level = 9
> 
> 
> [pac]
> 
> [ifp]
> ===
> 
> i am able to getent and  kinit for all of the AD user. but most of the user
> are not able to login via ssh /ad-password
> 
> getent passwd  et33015
> et33...@corp.corpcommon.com:*:1007629326:1007629326:Th Sub:/home/et33015:
> 
> and
> 
> kinit et33...@corp.corpcommon.com 

> -- 
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [6]: Permission denied.

[Lukas Slebodnik]

On (08/01/17 17:13), TomK wrote:
>On 1/8/2017 12:22 AM, TomK wrote:
>> Hey All,
>> 
>> Wanted to tap your experience a bit.  Do you recall under which
>> conditions this error can be triggered under?
>> 
>> (Sun Jan  8 00:15:17 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200):
>> received: [6 (Permission denied)][mds.xyz]
>> (Sun Jan  8 00:15:17 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply
>> called with result [6]: Permission denied.
>> 
>> Pass is OK (tested) and UNIX Login for AD users works on the servers but
>> not the clients.
>> 
>Resolved.  It was multiple domains being listed in sssd.conf that caused
>this.
>
Could you be more specific?
sssd works well with multiple domains.

LS

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] sshd[22490]: Failed password for invalid user

[rajat gupta]

few user are able to login. ipa ad-trust setup.

==
Jan  6 10:48:36 ilt-gif-ipa02 sshd[22490]: reverse mapping checking
getaddrinfo for ilp-noatun.man.cosng.net [146.213.128.135] failed -
POSSIBLE BREAK-IN ATTEMPT!
Jan  6 10:48:48 ilt-gif-ipa02 sshd[22490]: Invalid user et33015 from x.x.x.x
Jan  6 10:48:48 ilt-gif-ipa02 sshd[22490]: input_userauth_request: invalid
user et33015 [preauth]
Jan  6 10:48:48 ilt-gif-ipa02 sshd[22490]: error: PAM: User not known to
the underlying authentication module for illegal user et33015 from x.x.x.x
Jan  6 10:48:48 ilt-gif-ipa02 sshd[22490]: Failed keyboard-interactive/pam
for invalid user et33015 from x.x.x.x port 51270 ssh2
Jan  6 10:48:56 ilt-gif-ipa02 sshd[22490]: Failed password for invalid user
et33015 from 146.213.128.135 port 51270 ssh2
Jan  6 10:49:00 ilt-gif-ipa02 sshd[22490]: Failed password for invalid user
et33015 from 146.213.128.135 port 51270 ssh2
Jan  6 10:49:02 ilt-gif-ipa02 sshd[22490]: Failed password for invalid user
et33015 from 146.213.128.135 port 51270 ssh2
Jan  6 10:49:32 ilt-gif-ipa02 sshd[22490]: Connection closed by x.x.x.x
[preauth]



(Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
[get_server_status] (0x1000): Status of server
'ilt-gif-ipa01.ipa.preprod.local' is 'working'
(Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]] [get_port_status]
(0x1000): Port status of port 0 for server 'ilt-gif-ipa01.ipa.preprod.local'
is 'not working'
(Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
[fo_resolve_service_send] (0x0020): No available servers for service 'IPA'
(Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
[be_resolve_server_done] (0x1000): Server resolution failed: [5]:
Input/output error
(Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
[sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5
[Input/output error])
(Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]] [be_mark_offline]
(0x2000): Going offline!
(Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]] [be_mark_offline]
(0x2000): Initialize check_if_online_ptask.
(Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]] [be_ptask_create]
(0x0400): Periodic task [Check if online (periodic)] was created
(Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
[be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling
task 72 seconds from now [1483696200]
(Fri Jan  6 10:48:48 2017) [sssd[be[ipa.preprod.local]]]
[be_run_offline_cb] (0x0080): Going offline. Running callbacks

=

cat /etc/sssd/sssd.conf
[domain/ipa.preprod.local]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.preprod.local
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = ilt-gif-ipa02.ipa.preprod.local
chpass_provider = ipa
ipa_server = _srv_, ilt-gif-ipa01.ipa.preprod.local
ldap_tls_cacert = /etc/ipa/ca.crt
debug_level = 9


[sssd]
default_domain_suffix = corp.corpcommon.com
services = nss, sudo, pam, ssh
debug_level = 9


domains = ipa.preprod.local
[nss]
override_homedir = /home/%u
debug_level = 9



[pam]
debug_level = 9


[sudo]

[autofs]

[ssh]
debug_level = 9


[pac]

[ifp]
===

i am able to getent and  kinit for all of the AD user. but most of the user
are not able to login via ssh /ad-password

getent passwd  et33015
et33...@corp.corpcommon.com:*:1007629326:1007629326:Th Sub:/home/et33015:

and

kinit et33...@corp.corpcommon.com 
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Kerberos Clock Skew too great

[Rakesh Rajasekharan]

yes on the IPA server as well.. the offset isn't that high

 remote   refid  st t when poll reach   delay   offset
jitter
==
*ip-10-10-1-150.e 132.163.4.1012 u  119  128  3770.431   -0.279
0.348

So, my NTP server, the ipa client and the IPA master.. all seems to not
have a high offset or a jitter.

There were about 1500 hosts that were alerting for "clock skew" and the
issue went away only after I did a resync using ntpdate on all those hosts

Is it possible that so many higher number of minor offsets adds up and
causes it. Coz from the individual offset it looks much below the 5min limit

Or, is there a way to tell whats the offset limit its actually looking for.

Thanks,
Rakesh



On Mon, Jan 9, 2017 at 1:42 PM, Jakub Hrozek  wrote:

> On Mon, Jan 09, 2017 at 01:07:06PM +0530, Rakesh Rajasekharan wrote:
> > Hi,
> >
> > I am using a Freeipa 4.2.0 server.
> >
> > I sometimes see, "clock skew too great" errors in /var/log/krb5kdc.log.
> And
> > when this happens, usually logins or new ipa-cleint-install fails.
> >
> > When I checked on one of the hosts for which the clock skew was reported,
> >
> > #> ntpq -p
> > remote   refid  st t when poll reach   delay   offset
> > jitter
> > 
> ==
> > *ip-10-10-1-150.e 171.66.97.1262 u  869 1024  3770.4480.047
> > 0.142
>
> In general, 5 minutes is OK at least. But are you sure the server is also
> in sync or just the client against an NTP server (iow, are you sure you
> are checking the difference between a client and the KDC as well?)
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] Kerberos Clock Skew too great

[Jakub Hrozek]

On Mon, Jan 09, 2017 at 01:07:06PM +0530, Rakesh Rajasekharan wrote:
> Hi,
> 
> I am using a Freeipa 4.2.0 server.
> 
> I sometimes see, "clock skew too great" errors in /var/log/krb5kdc.log. And
> when this happens, usually logins or new ipa-cleint-install fails.
> 
> When I checked on one of the hosts for which the clock skew was reported,
> 
> #> ntpq -p
> remote   refid  st t when poll reach   delay   offset
> jitter
> ==
> *ip-10-10-1-150.e 171.66.97.1262 u  869 1024  3770.4480.047
> 0.142

In general, 5 minutes is OK at least. But are you sure the server is also
in sync or just the client against an NTP server (iow, are you sure you
are checking the difference between a client and the KDC as well?)

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] freeipa 4.4.0 and Ubuntu 14.04

[Jakub Hrozek]

On Fri, Jan 06, 2017 at 11:48:07AM -0500, Andy Brittingham wrote:
> Sorry for the delay, was doing some troubleshooting.
> 
> Here is what I know now:
> 
> The problem is on Ubuntu hosts using older sssd versions 1.11.8 (Ubuntu
> 14.04).
> 
> SSSD versions 1.13.4 (Ubuntu 16.04) and 1.13.3 (CentOS 6.8) both work.
> 
> Users in the admin group can't log into these hosts.
> 
> I created a newadmins group and assigned a new user to it. When I add the
> "User Administrator" role the new user can't log into the hosts with older
> sssd.
> 
> As soon as I delete the "User Administrator" role, new user has access
> again.

So is it a role membership or a group membership that makes the
difference?

> 
> I've pasted the last bit of logs from a sssd_domain log below. I'd be happy
> to forward the entire log, or additional logs if they will be helpful.

The log only captures a user lookup, not a login, sorry..

(This might be expected if you log in e.g. with an SSH key, in which
case journald should be the first thing to look at at least to poinpoint
which piece denied access..)

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project