Re: [Freeipa-users] Password and OTP auth

[Sumit Bose]

On Tue, May 16, 2017 at 06:05:06PM +0300, Andrey Dudin wrote:
> Thanks, but I think I have a problem.
> 
> I have test user:
> 
> [root@ipa-centos]# ipa user-show test
>   User login: test
>   First name: test
>   Last name: test
>   Home directory: /home/test
>   Login shell: /bin/sh
>   Principal name: t...@mydomain.com
>   Principal alias: t...@mydomain.com
>   Email address: t...@mydomain.com
>   UID: 15221
>   GID: 15221

As mentioned in the other thread there should be a listing of user auth
types here. Please try

ipa user-mod test --user-auth-type=password --user-auth-type=otp

to allow both password and 2-factor/otp authentication.

>   Account disabled: False
>   Password: True
>   Member of groups: trust admins, ipausers, admins
>   Kerberos keys available: True
> 
> 
> And test host:
> 
> [root@ipa-centos]# ipa host-show ipa-client.mydomain.com
>   Host name: ipa-client.mydomain.com
>   Principal name: host/ipa-client.mydomain@mydomain.com
>   Principal alias: host/ipa-client.mydomain@mydomain.com
>   SSH public key fingerprint: %SOME FINGERPRINTS%
>   Authentication Indicators: otp
>   Password: False
>   Keytab: True
>   Managed by: ipa-client.mydomain.com
> 
> 
> When I trying to login to ipa-client.mydomain.com with password+otptoken I
> have error:
> 
> [mynotebook]$ ssh t...@ipa-client.mydomain.com
> t...@ipa-client.mydomain.com's password:

Please check if ChallengeResponseAuthentication is enabled in
/etc/ssh/sshd_config on ipa-client.mydomain.com. If not please enable it
by setting 'ChallengeResponseAuthentication yes'.
> Permission denied, please try again.
> 
> 
> Same if I trying to use just password.
> 
> On ipa server in krb5kdc.log I see:
> 
> May 16 11:00:53 ipa-centos krb5kdc[2280](info): AS_REQ (6 etypes {18 17 16
> 23 25 26}) 10.0.1.22: NEEDED_PREAUTH: t...@mydomain.com for krbtgt/
> mydomain@mydomain.com, Additional pre-authentication required
> May 16 11:00:53 ipa-centos krb5kdc[2280](info): closing down fd 12
> May 16 11:00:53 ipa-centos krb5kdc[2280](info): AS_REQ (6 etypes {18 17 16
> 23 25 26}) 10.0.1.22: NEEDED_PREAUTH: t...@mydomain.com for krbtgt/
> mydomain@mydomain.com, Additional pre-authentication required
> May 16 11:00:53 ipa-centos krb5kdc[2280](info): closing down fd 12
> May 16 11:00:53 ipa-centos krb5kdc[2280](info): AS_REQ (6 etypes {18 17 16
> 23 25 26}) 10.0.1.22: ISSUE: authtime 1494946853, etypes {rep=18 tkt=18
> ses=18}, t...@mydomain.com for krbtgt/mydomain@mydomain.com
> May 16 11:00:53 ipa-centos krb5kdc[2280](info): closing down fd 12
> May 16 11:00:53 ipa-centos krb5kdc[2280](info): TGS_REQ (6 etypes {18 17 16
> 23 25 26}) 10.0.1.22: HIGHER_AUTHENTICATION_REQUIRED: authtime 1494946853,
> t...@mydomain.com for host/ipa-client.mydomain@mydomain.com, Required
> auth indicators not present in ticket: otp

The otp authentication indicator is missing in the Kerberos ticket of
the user. I assume that the ticket was requested only with the password.
Please see above what might be missing.

HTH

bye,
Sumit

> May 16 11:00:53 ipa-centos krb5kdc[2280](info): closing down fd 12
> May 16 11:00:53 ipa-centos krb5kdc[2280](info): TGS_REQ (6 etypes {18 17 16
> 23 25 26}) 10.0.1.22: HIGHER_AUTHENTICATION_REQUIRED: authtime 1494946853,
> t...@mydomain.com for host/ipa-client.mydomain....@mydomain.com, Required
> auth indicators not present in ticket: otp
> May 16 11:00:53 ipa-centos krb5kdc[2280](info): closing down fd 12
> 
> What's wrong?
> 
> 2017-05-16 17:16 GMT+03:00 Sumit Bose <sb...@redhat.com>:
> 
> > On Tue, May 16, 2017 at 04:48:42PM +0300, Andrey Dudin wrote:
> > > Hello all.
> > >
> > > tell me please. Is it possible to use password and otp auth at the one
> > > moment?
> > >
> > > For example I have DEV/STAGE servers and want to be able use password
> > auth
> > > for ssh, but for PROD servers I want to use OTP auth for same user.
> >
> > Authentication indicators can be used for this. If you add
> >
> > ipa host-mod --auth-ind=otp prod.server
> >
> > Only 2-factor authentication should be possible on prod.server. But
> > please note that e.g. ssh-key based authentication will still be
> > possible as well.
> >
> > HTH
> >
> > bye,
> > Sumit
> >
> > > --
> > > 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
> >
> 
> 
> 
> -- 
> С уважением Дудин Андрей

-- 
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] Password and OTP auth

[Sumit Bose]

On Tue, May 16, 2017 at 04:48:42PM +0300, Andrey Dudin wrote:
> Hello all.
> 
> tell me please. Is it possible to use password and otp auth at the one
> moment?
> 
> For example I have DEV/STAGE servers and want to be able use password auth
> for ssh, but for PROD servers I want to use OTP auth for same user.

Authentication indicators can be used for this. If you add

ipa host-mod --auth-ind=otp prod.server

Only 2-factor authentication should be possible on prod.server. But
please note that e.g. ssh-key based authentication will still be
possible as well.

HTH

bye,
Sumit

> -- 
> 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] Authenticate on GNOME display manager with freeipa

[Sumit Bose]

On Fri, May 12, 2017 at 03:00:42PM +0200, tuxderlinuxfuch...@gmail.com wrote:
> It worked with pam_mkhomedir. So I don't see anything left to do at the
> moment
> 

ah, I thought ...

> 
> On 12-May-17 12:52 PM, Sumit Bose wrote:
> > On Fri, May 12, 2017 at 12:11:28PM +0200, tuxderlinuxfuch...@gmail.com 
> > wrote:
> >> The directory didn't exist

... meant that pam_mkhomedir didn't create the directory properly. Glad
it works for you now.

bye,
Sumit

> > Then I guess that the process doesn't has the needed permissions during
> > the session phase anymore. Please try to replace pam_mkhomedir by
> > pam_oddjob_mkhomedir. This will try to create the directory via oddjobd
> > which runs with higher privileges.
> >
> > HTH
> >
> > bye,
> > Sumit
> >
> >>
> >> On 12-May-17 11:48 AM, Sumit Bose wrote:
> >>> On Fri, May 12, 2017 at 11:25:04AM +0200, tuxderlinuxfuch...@gmail.com 
> >>> wrote:
> >>>> Thanks!
> >>>>
> >>>> I followed this manual:
> >>>> https://help.ubuntu.com/lts/serverguide/sssd-ad.html#sssd-ad-mkhomedir
> >>>>
> >>>> added the line
> >>>>
> >>>> sessionrequiredpam_mkhomedir.so skel=/etc/skel/ umask=0022
> >>>>
> >>>> to the file /etc/pam.d/common-session (find attached)
> >>>>
> >>>>
> >>> Have you checked if /home/vmuser1 exists and has the right permissions
> >>> so that the user can create files in the directory?
> >>>
> >>> bye,
> >>> Sumit
> >>>
> >> -- 
> >> 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

-- 
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] Authenticate on GNOME display manager with freeipa

[Sumit Bose]

On Fri, May 12, 2017 at 12:11:28PM +0200, tuxderlinuxfuch...@gmail.com wrote:
> The directory didn't exist

Then I guess that the process doesn't has the needed permissions during
the session phase anymore. Please try to replace pam_mkhomedir by
pam_oddjob_mkhomedir. This will try to create the directory via oddjobd
which runs with higher privileges.

HTH

bye,
Sumit

> 
> 
> On 12-May-17 11:48 AM, Sumit Bose wrote:
> > On Fri, May 12, 2017 at 11:25:04AM +0200, tuxderlinuxfuch...@gmail.com 
> > wrote:
> >> Thanks!
> >>
> >> I followed this manual:
> >> https://help.ubuntu.com/lts/serverguide/sssd-ad.html#sssd-ad-mkhomedir
> >>
> >> added the line
> >>
> >> sessionrequiredpam_mkhomedir.so skel=/etc/skel/ umask=0022
> >>
> >> to the file /etc/pam.d/common-session (find attached)
> >>
> >>
> > Have you checked if /home/vmuser1 exists and has the right permissions
> > so that the user can create files in the directory?
> >
> > bye,
> > Sumit
> >
> 
> -- 
> 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] k5login loophole even account is disabled on FreeIPA

[Sumit Bose]

On Fri, May 12, 2017 at 08:41:07AM +0200, Sumit Bose wrote:
> On Fri, May 12, 2017 at 09:35:40AM +0300, Alexander Bokovoy wrote:
> > On pe, 12 touko 2017, Thomas Lau wrote:
> > > Folks,
> > > 
> > > let's say I am user thomas, and user "temp1" already marked as "disabled"
> > > on FreeIPA, but tho...@domain.com is on /home/temp1/.k5login list, how 
> > > come
> > > I could still "sudo su - temp1"? It seems skip the checking on FreeIPA 
> > > even
> > > account is disabled. Did I miss any setting or it's normal?
> > This is normal.
> > 
> > sudo brings you to root. PAM module for su (/etc/pam.d/su) has this:
> > 
> >  auth   sufficient  pam_rootok.so
> > 
> > E.g. if su is executed as root, it is enough, no other authentication
> > checks are done.
> 
> And no authorization checks either becasue there is 
> 
> account sufficient  pam_succeed_if.so uid = 0 use_uid quiet

and btw, this is completely unrelated to .k5login, even if you remove
tho...@domain.com from the file it would still work.

bye,
Sumit

> 
> > 
> > -- 
> > / Alexander Bokovoy
> > 
> > -- 
> > 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

-- 
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] k5login loophole even account is disabled on FreeIPA

[Sumit Bose]

On Fri, May 12, 2017 at 09:35:40AM +0300, Alexander Bokovoy wrote:
> On pe, 12 touko 2017, Thomas Lau wrote:
> > Folks,
> > 
> > let's say I am user thomas, and user "temp1" already marked as "disabled"
> > on FreeIPA, but tho...@domain.com is on /home/temp1/.k5login list, how come
> > I could still "sudo su - temp1"? It seems skip the checking on FreeIPA even
> > account is disabled. Did I miss any setting or it's normal?
> This is normal.
> 
> sudo brings you to root. PAM module for su (/etc/pam.d/su) has this:
> 
>  auth sufficient  pam_rootok.so
> 
> E.g. if su is executed as root, it is enough, no other authentication
> checks are done.

And no authorization checks either becasue there is 

account sufficient  pam_succeed_if.so uid = 0 use_uid quiet

bye,
Sumit

> 
> -- 
> / Alexander Bokovoy
> 
> -- 
> 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] Authenticate on GNOME display manager with freeipa

[Sumit Bose]

On Fri, May 12, 2017 at 12:50:08AM +0200, tuxderlinuxfuch...@gmail.com wrote:
> I have attached the syslog with gdm debug mode enabled
> 
> 
> On 11-May-17 1:54 PM, Sumit Bose wrote:
> > On Thu, May 11, 2017 at 01:29:33PM +0200, tuxderlinuxfuch...@gmail.com 
> > wrote:
> >> Hello,
> >>
> >> I have attached the requested files.
> > The logs indicate that access was granted by SSSD and that gdm even
> > called pam_open_session.
> >
> > Did gdm login worked with the 'allow all' rule? Are there any other
> > hints in the system or gdm logs with gdm might have failed?
> >
> > bye,
> > Sumit
> >
> >> Thanks in advance!
> >>
> >> On 10-May-17 9:42 PM, Sumit Bose wrote:
> >>> On Tue, May 09, 2017 at 11:12:13PM +0200, tuxderlinuxfuch...@gmail.com 
> >>> wrote:
> >>>> Hello everyone,
> >>>>
> >>>> I set up my freeIPA instance and it works very well for my client
> >>>> computers (Ubuntu Desktop 16.04.2 LTS), I can login via SSH using a
> >>>> freeIPA managed user account.
> >>>>
> >>>> My own HBAC rule also works for that. I disabled the "allow all" rule
> >>>> and created my own one. Works fine for SSH.
> >>>>
> >>>> But I cannot login to the GNOME 3 Desktop on the client. I used the
> >>>> netinstall ISO image of Ubuntu. During installation, I have chose
> >>>> "Ubuntu GNOME Desktop" as the only desktop.
> >>>>
> >>>> So my display manager is gdm3.
> >>>>
> >>>> I added the "gdm" and "gdm-password" services to my HBAC rule. To be on
> >>>> the safe side, I rebooted the client machine. But I still can't login to
> >>>> the GNOME Desktop with an account that can login via SSH.
> >>>>
> >>>> So the services in my rule are
> >>>>
> >>>> login, gdm, gdm-password
> >>>>
> >>>> If you need any logs or other information, I will provide them.
> >>> Please send sssd_pam.log and sssd_domain.name.log with debug_level=10 in
> >>> the [pam] and [domain/...] section of sssd.conf.
> >>>
> >>> bye,
> >>> Sumit
> >>>
> >>>> Thanks in advance!
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> -- 
> >>>> 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
> 

> 

> May 11 23:41:55 ubugdm /usr/lib/gdm3/gdm-x-session[1741]: (II) This device 
> may have been added with another device file.
> May 11 23:41:55 ubugdm gdm-x-session: Running session message bus
> May 11 23:41:55 ubugdm gdm3: GdmManager: trying to register new display
> May 11 23:41:55 ubugdm gdm3: GdmSession: Setting display device: /dev/tty2
> May 11 23:41:55 ubugdm gdm3: using ut_user vmuser1
> May 11 23:41:55 ubugdm gdm3: Writing login record
> May 11 23:41:55 ubugdm gdm3: using ut_type USER_PROCESS
> May 11 23:41:55 ubugdm gdm3: using ut_tv time 1494538915
> May 11 23:41:55 ubugdm gdm3: using ut_pid 1741
> May 11 23:41:55 ubugdm gdm3: using ut_host :1
> May 11 23:41:55 ubugdm gdm3: using ut_line tty2
> May 11 23:41:55 ubugdm gdm3: Writing wtmp session record to /var/log/wtmp
> May 11 23:41:55 ubugdm gdm3: Adding or updating utmp record for login
> May 11 23:41:55 ubugdm gdm3: GdmLocalDisplayFactory: display status changed: 2
> May 11 23:41:55 ubugdm gdm-x-session: Running X session
> May 11 23:41:55 ubugdm gdm-x-session: Trying script /etc/gdm3/Prime/:1
> May 11 23:41:55 ubugdm gdm-x-session: script /etc/gdm3/Prime/:1 not found; 
> skipping
> May 11 23:41:55 ubugdm gdm-x-session: Trying script /etc/gdm3/Prime/Default
> May 11 23:41:55 ubugdm gdm-x-session: Running process: /etc/gdm3/Prime/Default
> May 11 23:41:55 ubugdm gdm-x-session: GdmSlave: script environment: DISPLAY=:1
> May 11 23:41:55 ubugdm gdm-x-session: GdmSlave: script environment: 
> SHELL=/bin/sh
> May 11 23:41:55 ubugdm gdm-x-session: GdmSlave: script environment: 
> XAUTHORITY=/run/user/12644/gdm/Xauthority
> May 11 23:41:55 ubugdm gdm-x-session: GdmSlave: script environment: 
> RUNNING_UNDER_GDM=true
> May 11 23:41:55 ubugdm gdm-x-session: GdmSlave: script environment: HOME=/
> May 11 23:41:55 ubugdm gdm-x-session: GdmSlave: script environment: PWD=/
> May 11 23:41:55 ubugdm gdm-x-session: GdmSlave: script environment: 
> PATH=/u

Re: [Freeipa-users] Preauth module encrypted_challenge Cannot read password

[Sumit Bose]

On Thu, May 11, 2017 at 01:07:25PM +, Berkouwer, Walter wrote:
> Hello
> 
> I am trying to setup an IPA configuration at an remote site. I got the 
> ssh-connection working with a 6.6 client ( ipa-client version 3.0.0), but I 
> can't get it working with a 7.3 client ( ipa-client version 4.4.0 ).
> 
> Version of the server is 4.4.0.
> 
> Can some help me with this problem.
> 
> >From the logfiles I got the following messages.
> /var/log/secure:
> 
> May 11 13:05:10 edsnfmwsv009 sshd[14026]: pam_sss(sshd:auth): authentication 
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.72.145 
> user=berkouwa
> May 11 13:05:10 edsnfmwsv009 sshd[14026]: pam_sss(sshd:auth): received for 
> user berkouwa: 17 (Failure setting user credentials)
> May 11 13:05:10 edsnfmwsv009 sshd[14021]: error: PAM: Authentication failure 
> for berkouwa from 192.168.72.145
> May 11 13:05:10 edsnfmwsv009 sshd[14021]: Postponed keyboard-interactive for 
> berkouwa from 192.168.72.145 port 51772 ssh2 [preauth]
> 
> /var/log/sssd/krb5_child.log:
> 
> (Thu May 11 13:05:10 2017) [[sssd[krb5_child[14030 
> [sss_child_krb5_trace_cb] (0x4000): [14030] 1494500710.640900: Received 
> cookie: MIT
> 
> (Thu May 11 13:05:10 2017) [[sssd[krb5_child[14030 [sss_krb5_responder] 
> (0x4000): Got question [password].
> (Thu May 11 13:05:10 2017) [[sssd[krb5_child[14030 [sss_krb5_prompter] 
> (0x4000): sss_krb5_prompter name [(null)] banner [(null)] num_prompts [1] 
> EINVAL.
> (Thu May 11 13:05:10 2017) [[sssd[krb5_child[14030 [sss_krb5_prompter] 
> (0x0020): Cannot handle password prompts.
> (Thu May 11 13:05:10 2017) [[sssd[krb5_child[14030 [sss_krb5_prompter] 
> (0x4000): Prompt [0][Password for berkouwa@EDSN.LOCAL].
> (Thu May 11 13:05:10 2017) [[sssd[krb5_child[14030 
> [sss_child_krb5_trace_cb] (0x4000): [14030] 1494500710.640958: Preauth module 
> encrypted_challenge (138) (real) returned: -1765328254/Cannot read password
> 
> (Thu May 11 13:05:10 2017) [[sssd[krb5_child[14030 [get_and_save_tgt] 
> (0x0400): krb5_get_init_creds_password returned [-1765328254} during pre-auth.

Errors are expected during the pre-auth phase, I guess I should make the
debug message more clear about it.

The actual error is:

[[sssd[krb5_child[17076 [sss_get_ccache_name_for_principal] (0x2000): 
krb5_cc_cache_match failed: [-1750600185][Invalid UID in persistent keyring 
name]

Please check your /etc/krb5.conf if accidentally there are some
additional config option on the same line as 'default_ccache_name =
KEYRING:persistent:%{uid}'.

HTH

bye,
Sumit

> (Thu May 11 13:05:10 2017) [[sssd[krb5_child[14030 [k5c_send_data] 
> (0x0200): Received error code 0
> (Thu May 11 13:05:10 2017) [[sssd[krb5_child[14030 [pack_response_packet] 
> (0x2000): response packet size: [12]
> (Thu May 11 13:05:10 2017) [[sssd[krb5_child[14030 [k5c_send_data] 
> (0x4000): Response sent.
> (Thu May 11 13:05:10 2017) [[sssd[krb5_child[14030 [main] (0x0400): 
> krb5_child completed successfully
> 
> I placed the full logfiles and the sssd.conf here: 
> https://drive.google.com/open?id=0B66tVXzcZy1CdFZNb1dvUjk4Tnc
> 
> Walter

> -- 
> 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] Authenticate on GNOME display manager with freeipa

[Sumit Bose]

On Thu, May 11, 2017 at 01:29:33PM +0200, tuxderlinuxfuch...@gmail.com wrote:
> Hello,
> 
> I have attached the requested files.

The logs indicate that access was granted by SSSD and that gdm even
called pam_open_session.

Did gdm login worked with the 'allow all' rule? Are there any other
hints in the system or gdm logs with gdm might have failed?

bye,
Sumit

> 
> Thanks in advance!
> 
> On 10-May-17 9:42 PM, Sumit Bose wrote:
> > On Tue, May 09, 2017 at 11:12:13PM +0200, tuxderlinuxfuch...@gmail.com 
> > wrote:
> >> Hello everyone,
> >>
> >> I set up my freeIPA instance and it works very well for my client
> >> computers (Ubuntu Desktop 16.04.2 LTS), I can login via SSH using a
> >> freeIPA managed user account.
> >>
> >> My own HBAC rule also works for that. I disabled the "allow all" rule
> >> and created my own one. Works fine for SSH.
> >>
> >> But I cannot login to the GNOME 3 Desktop on the client. I used the
> >> netinstall ISO image of Ubuntu. During installation, I have chose
> >> "Ubuntu GNOME Desktop" as the only desktop.
> >>
> >> So my display manager is gdm3.
> >>
> >> I added the "gdm" and "gdm-password" services to my HBAC rule. To be on
> >> the safe side, I rebooted the client machine. But I still can't login to
> >> the GNOME Desktop with an account that can login via SSH.
> >>
> >> So the services in my rule are
> >>
> >> login, gdm, gdm-password
> >>
> >> If you need any logs or other information, I will provide them.
> > Please send sssd_pam.log and sssd_domain.name.log with debug_level=10 in
> > the [pam] and [domain/...] section of sssd.conf.
> >
> > bye,
> > Sumit
> >
> >>
> >> Thanks in advance!
> >>
> >>
> >>
> >>
> >> -- 
> >> 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] Authenticate on GNOME display manager with freeipa

[Sumit Bose]

On Tue, May 09, 2017 at 11:12:13PM +0200, tuxderlinuxfuch...@gmail.com wrote:
> Hello everyone,
> 
> I set up my freeIPA instance and it works very well for my client
> computers (Ubuntu Desktop 16.04.2 LTS), I can login via SSH using a
> freeIPA managed user account.
> 
> My own HBAC rule also works for that. I disabled the "allow all" rule
> and created my own one. Works fine for SSH.
> 
> But I cannot login to the GNOME 3 Desktop on the client. I used the
> netinstall ISO image of Ubuntu. During installation, I have chose
> "Ubuntu GNOME Desktop" as the only desktop.
> 
> So my display manager is gdm3.
> 
> I added the "gdm" and "gdm-password" services to my HBAC rule. To be on
> the safe side, I rebooted the client machine. But I still can't login to
> the GNOME Desktop with an account that can login via SSH.
> 
> So the services in my rule are
> 
> login, gdm, gdm-password
> 
> If you need any logs or other information, I will provide them.

Please send sssd_pam.log and sssd_domain.name.log with debug_level=10 in
the [pam] and [domain/...] section of sssd.conf.

bye,
Sumit

> 
> 
> Thanks in advance!
> 
> 
> 
> 
> -- 
> 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] GSSAPI authentication from trusted AD domain

[Sumit Bose]

On Wed, May 03, 2017 at 11:28:18AM +0200, Tiemen Ruiten wrote:
> Tickets on the FreeIPA host after connecting (with a password):
> 
> [adm.tie...@clients.rdmedia.com@neodymium ~]$ klist
> Ticket cache: KEYRING:persistent:998801112:krb_ccache_ZzERoB1
> Default principal: adm.tie...@clients.rdmedia.com
> 
> Valid starting   Expires  Service principal
> 05/03/2017 11:26:03  05/03/2017 21:26:03  krbtgt/
> clients.rdmedia@clients.rdmedia.com
> renew until 05/04/2017 11:26:03
> 
> 
> 
> Tickets on the AD laptop after a connection attempt:
> 
> C:\Users\adm.tiemen.CLIENTS>klist
> 
> Current LogonId is 0:0x587aa
> 
> Cached Tickets: (2)
> 
> #0> Client: adm.tiemen @ CLIENTS.RDMEDIA.COM
> Server: krbtgt/CLIENTS.RDMEDIA.COM @ CLIENTS.RDMEDIA.COM
> KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
> Ticket Flags 0x40e1 -> forwardable renewable initial
> pre_authent name_canonicalize
> Start Time: 5/3/2017 11:12:46 (local)
> End Time:   5/3/2017 21:12:46 (local)
> Renew Time: 5/10/2017 11:12:46 (local)
> Session Key Type: AES-256-CTS-HMAC-SHA1-96
> Cache Flags: 0x1 -> PRIMARY
> Kdc Called: vm-win-01.clients.rdmedia.com
> 
> #1> Client: adm.tiemen @ CLIENTS.RDMEDIA.COM
> Server: LDAP/vm-win-01.clients.rdmedia.com/clients.rdmedia.com @
> CLIENTS.RDMEDIA.COM
> KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
> Ticket Flags 0x40a5 -> forwardable renewable pre_authent
> ok_as_delegate name_canonicalize
> Start Time: 5/3/2017 11:12:46 (local)
> End Time:   5/3/2017 21:12:46 (local)
> Renew Time: 5/10/2017 11:12:46 (local)
> Session Key Type: AES-256-CTS-HMAC-SHA1-96
> Cache Flags: 0
> Kdc Called: vm-win-01.clients.rdmedia.com

There is no ticket for
host/neodymium.test.ams.i.rdmedia@test.ams.i.rdmedia.com
nor a cross-realm ticket
krbtgt/test.ams.i.rdmedia@clients.rdmedia.com

So it looks the ssh client in the Windows host didn't try to get a
Kerberos ticket for the IPA client. Did you use the FQDN
neodymium.test.ams.i.rdmedia.com when trying to connect to the IPA
client?

According to the logs it looks like you are using kitty, have you tried
to use putty?

bye,
Sumit

> 
> 
> 
> 
> On 2 May 2017 at 19:45, Tiemen Ruiten <t.rui...@rdmedia.com> wrote:
> 
> > It's a CentOS 7.3 host, the version of sssd is 1.14.0, so there's no need
> > for mapping. However on the AD host:
> >
> > Microsoft Windows [Version 6.3.9600]
> >
> > (c) 2013 Microsoft Corporation. All rights reserved.
> >
> >
> > adm.tiemen@VM-WIN-01 C:\Users\adm.tiemen>klist
> >
> >
> > Current LogonId is 0:0x603b58
> >
> >
> > Cached Tickets: (0)
> >
> >
> > adm.tiemen@VM-WIN-01 C:\Users\adm.tiemen>
> >
> > Note that this is the domain controller and I'm logged in using the
> > experimental Win32-OpenSSH server. Not sure if that makes a difference. I
> > am not currently in the office, so unfortunately can't turn on the only
> > joined laptop in this domain.
> >
> > How can I ensure a proper ticket is generated?
> >
> > On 2 May 2017 at 18:25, Sumit Bose <sb...@redhat.com> wrote:
> >
> >> On Tue, May 02, 2017 at 05:46:34PM +0200, Tiemen Ruiten wrote:
> >> > I think I just realised that my expectation may be wrong: GSSAPI login
> >> with
> >> > a FreeIPA user logged in on an AD host to a FreeIPA host works. So is it
> >> > correct to also expect passwordless login with an AD user to a FreeIPA
> >> host?
> >>
> >> The AD user case should work as well.
> >>
> >> First please send the SSSD version you use on the IPA client,
> >> alternatively you can check if
> >> /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists or not. This
> >> would tell if SSSD can map the user name to the Kerberos principal of if
> >> additional configuration is needed.
> >>
> >> On the AD host please check after trying to connect with ssh if there is
> >> a proper service ticket for the IPA client by calling 'klist' in cmd.exe
> >> or PowerShell.
> >>
> >> bye,
> >> Sumit
> >>
> >> >
> >> > On 2 May 2017 at 17:40, Jason B. Nance <ja...@tresgeek.net> wrote:
> >> >
> >> > > Hi Tiemen,
> >> > >
> >> > > To be clear, what I'm trying to do: log in from an AD account
> >> > > (adm.tiemen), from an AD host (leon.clients.rdmedia.com) 

Re: [Freeipa-users] GSSAPI authentication from trusted AD domain

[Sumit Bose]

On Tue, May 02, 2017 at 05:46:34PM +0200, Tiemen Ruiten wrote:
> I think I just realised that my expectation may be wrong: GSSAPI login with
> a FreeIPA user logged in on an AD host to a FreeIPA host works. So is it
> correct to also expect passwordless login with an AD user to a FreeIPA host?

The AD user case should work as well. 

First please send the SSSD version you use on the IPA client,
alternatively you can check if
/var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists or not. This
would tell if SSSD can map the user name to the Kerberos principal of if
additional configuration is needed.

On the AD host please check after trying to connect with ssh if there is
a proper service ticket for the IPA client by calling 'klist' in cmd.exe
or PowerShell.

bye,
Sumit

> 
> On 2 May 2017 at 17:40, Jason B. Nance  wrote:
> 
> > Hi Tiemen,
> >
> > To be clear, what I'm trying to do: log in from an AD account
> > (adm.tiemen), from an AD host (leon.clients.rdmedia.com) to a FreeIPA
> > host (neodymium.test.ams.i.rdmedia.com) with the same AD account. I
> > expect to be logged in through GSSAPI, instead I get a password prompt.
> >
> > I'm assuming that you are coming from a Windows client that is domain
> > joined and logged into that Windows client with the same domain credentials
> > that you are using to connect to the IPA-joined host.  Do you also have
> > your SSH client configured to attempt GSSAPI?  It appears that you do from
> > the logs you provided but I'm just double-checking.
> >
> > In my setup I've found that this feature does not work all of the time.
> > I've not yet been able to track it down and I'm assuming it has something
> > to do with connections to domain controllers timing out, but at this point
> > that is speculation.
> >
> > So to answer your question, yes, that should work.  Sorry I don't have
> > more information for you, I guess I'm basically "me too"ing your post.
> >
> > Regards,
> >
> > j
> >
> > Is this supposed to work? Did I miss something?
> >
> > Below the SSH log from the FreeIPA host with LogLevel DEBUG3:
> >
> > May  2 17:10:32 neodymium sshd[572]: debug3: fd 5 is not O_NONBLOCK
> > May  2 17:10:32 neodymium sshd[572]: debug1: Forked child 752.
> > May  2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: entering fd
> > = 8 config len 922
> > May  2 17:10:32 neodymium sshd[572]: debug3: ssh_msg_send: type 0
> > May  2 17:10:32 neodymium sshd[572]: debug3: send_rexec_state: done
> > May  2 17:10:32 neodymium sshd[752]: debug3: oom_adjust_restore
> > May  2 17:10:32 neodymium sshd[752]: Set /proc/self/oom_score_adj to 0
> > May  2 17:10:32 neodymium sshd[752]: debug1: rexec start in 5 out 5
> > newsock 5 pipe 7 sock 8
> > May  2 17:10:32 neodymium sshd[752]: debug1: inetd sockets after dupping:
> > 3, 3
> > May  2 17:10:32 neodymium sshd[752]: Connection from 192.168.10.155 port
> > 53106 on 192.168.50.63 port 22
> > May  2 17:10:32 neodymium sshd[752]: debug1: Client protocol version 2.0;
> > client software version PuTTY_KiTTY
> > May  2 17:10:32 neodymium sshd[752]: debug1: no match: PuTTY_KiTTY
> > May  2 17:10:32 neodymium sshd[752]: debug1: Enabling compatibility mode
> > for protocol 2.0
> > May  2 17:10:32 neodymium sshd[752]: debug1: Local version string
> > SSH-2.0-OpenSSH_6.6.1
> > May  2 17:10:32 neodymium sshd[752]: debug2: fd 3 setting O_NONBLOCK
> > May  2 17:10:32 neodymium sshd[752]: debug3: ssh_sandbox_init: preparing
> > rlimit sandbox
> > May  2 17:10:32 neodymium sshd[752]: debug2: Network child is on pid 753
> > May  2 17:10:32 neodymium sshd[752]: debug3: preauth child monitor started
> > May  2 17:10:32 neodymium sshd[752]: debug1: SELinux support disabled
> > [preauth]
> > May  2 17:10:32 neodymium sshd[752]: debug3: privsep user:group 74:74
> > [preauth]
> > May  2 17:10:32 neodymium sshd[752]: debug1: permanently_set_uid: 74/74
> > [preauth]
> > May  2 17:10:32 neodymium sshd[752]: debug1: list_hostkey_types:
> > ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
> > May  2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering:
> > type 42 [preauth]
> > May  2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive_expect
> > entering: type 43 [preauth]
> > May  2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive entering
> > [preauth]
> > May  2 17:10:32 neodymium sshd[752]: debug3: mm_request_receive entering
> > May  2 17:10:32 neodymium sshd[752]: debug3: monitor_read: checking
> > request 42
> > May  2 17:10:32 neodymium sshd[752]: debug3: mm_request_send entering:
> > type 43
> > May  2 17:10:32 neodymium sshd[752]: debug1: SSH2_MSG_KEXINIT sent
> > [preauth]
> > May  2 17:10:32 neodymium sshd[752]: debug1: SSH2_MSG_KEXINIT received
> > [preauth]
> > May  2 17:10:32 neodymium sshd[752]: debug2: kex_parse_kexinit:
> > gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,gss-group1-sha1-toWM5Slw5Ew8Mqkay+
> > al2g==,gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,curve
> > 

Re: [Freeipa-users] Malformed representation of principal - krb5_child.log

[Sumit Bose]

On Fri, Apr 28, 2017 at 02:54:44PM +, Sullivan, Daniel [CRI] wrote:
> HI,
> 
> I haven’t posted in a while, I hope everybody is doing well.  I have a 
> problem that I am having a difficult time diagnosing.  To start, I want to 
> say that we have a pretty large IPA environment.  It generally works good.  
> Most of our servers are of the same flavor RHEL6/7, and pull down their 
> sssd/IPA RPMs from a standard repo.  We also deploy sssd/ipa-client from 
> SaltStack, so there’s not much variation on configuration.  I have a client 
> that is being very finicky, I am getting a message that says "Malformed 
> representation of principal” in my krb5_child.log (when trying to log in).  
> I’m really kind of an ends with the right way to troubleshoot this further.  
> Here’s what I know;
> 
> 1) I can kinit -k as root
> 2) I can kinit user@domain, even for the user in the sssd logs
> 3) I’ve blown away /var/lib/sss, deleted /etc/krb*, reinstalled sssd-common, 
> sssd, & ipa-client.
> 
> My logs are below.  Would somebody be able to perhaps provide input on the 
> best way to further troubleshoot this issue?
> 
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x0400): 
> krb5_child started.
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] 
> (0x1000): total buffer size: [174]
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] 
> (0x0100): cmd [241] uid [339788572] gid [339788572] validate [true] 
> enterprise principal [false] offline [false] UPN [user@domain@DOMAIN]

There was an issue in an older version of SSSD which saved a wrong UPN
in the cache. Please check if the latest version of SSSD for your
platform installed, stop SSSD, remove the cache file in
/var/lib/sss/db/, start SSSD and try again.

If you do not want to remove the cache completely you can use e.g.
ldbedit to delete the offending entry individually, search for
user@domain@DOMAIN.

HTH

bye,
Sumit

> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] 
> (0x2000): No old ccache
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [unpack_buffer] 
> (0x0100): ccname: [FILE:/tmp/krb5cc_339788572_XX] old_ccname: [not set] 
> keytab: [/etc/krb5.keytab]
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_precreate_ccache] 
> (0x4000): Recreating ccache
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_setup_fast] 
> (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/server.fqdn@DOMAIN]
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 
> [find_principal_in_keytab] (0x4000): Trying to find principal 
> host/server.fqdn@DOMAIN in keytab.
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [match_principal] 
> (0x1000): Principal matched to the sample (host/server.fqdn@DOMAIN).
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [check_fast_ccache] 
> (0x0200): FAST TGT is still valid.
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [become_user] (0x0200): 
> Trying to become user [339788572][339788572].
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x2000): 
> Running as [339788572][339788572].
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_setup] (0x2000): 
> Running as [339788572][339788572].
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [k5c_setup] (0x0020): 
> 2529: [-1765328250][Malformed representation of principal]
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x0020): 
> krb5_child_setup failed.
> (Thu Apr 27 20:17:24 2017) [[sssd[krb5_child[8722 [main] (0x0020): 
> krb5_child failed!
> 
> (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [read_pipe_handler] 
> (0x0400): EOF received, client finished
> (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [parse_krb5_child_response] 
> (0x0020): message too short.
> (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [krb5_auth_done] (0x0040): 
> Could not parse child response [22]: Invalid argument
> (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] [check_wait_queue] 
> (0x1000): Wait queue for user [user@domain] is empty.
> (Thu Apr 27 20:17:24 2017) [sssd[be[ipa.domain]]] [krb5_auth_queue_done] 
> (0x0040): krb5_auth_recv failed with: 22
> (Thu Apr 27 20:17:24 2017) [sssd[be[iipa.domain]]] 
> [ipa_pam_auth_handler_krb5_done] (0x0040): KRB5 auth failed [22]: Invalid 
> argument
> 
> I appreciate your help with this.
> 
> Thank you,
> 
> Dan Sullivan
> 
> 
> -- 
> 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] Fedora 25 - SSSD: Smart card login is broken

[Sumit Bose]

On Tue, Apr 25, 2017 at 12:38:11PM -0500, Michael Rainey (Contractor) wrote:
> Hello,
> 
> While using Fedora 25 we noticed smart card login is broken with the latest
> update to SSSD.  A month or so ago a patch was created to fix the same
> issue.  Here are some of the details:
> 
> Before Update:
> 
> sssd.x86_641.15.2-1.fc25sb1(was 1.15.2-1.fc25 before patch)
> 
> After Update:
> 
> sssd.x86_641.15.2-2.fc25
> 
> I was able to compared this to a freshly updated system to a system which
> didn't receive the same update so I am confident lies with the package
> update.

ah, sorry, this is my fault, I forgot to create a Fedora bugzilla
ticket, there is one for RHEL but not for Fedora. I just created
https://bugzilla.redhat.com/show_bug.cgi?id=1445680 to track this for
Fedora.

In the meantime please find packages with the latest Fedora version plus
the patch at
https://koji.fedoraproject.org/koji/taskinfo?taskID=19211021.

> 
> I have also noted the "lock screen when card removed" feature is not
> working.

Did this change with the update as well? How did you configure the
feature?

bye,
Sumit

> 
> Your help is greatly appreciated.
> 
> Thank you,
> 
> -- 
> *Michael Rainey*

> -- 
> 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, krb5_child.log: Received error code 1432158221

[Sumit Bose]

On Mon, Apr 24, 2017 at 02:24:34PM +0200, Harald Dunkel wrote:
> Hi folks,
> 
> some colleagues have to enter their password 3 times (or even
> more) to authenticate. krb5_child.log shows
> 
> (Mon Apr  3 10:45:20 2017) [[sssd[krb5_child[5116 [switch_creds] 
> (0x0200): Switch user to [657][100].
> (Mon Apr  3 10:45:20 2017) [[sssd[krb5_child[5116 [switch_creds] 
> (0x0200): Switch user to [0][0].
> (Mon Apr  3 10:45:20 2017) [[sssd[krb5_child[5116 [check_fast_ccache] 
> (0x0200): FAST TGT is still valid.
> (Mon Apr  3 10:45:20 2017) [[sssd[krb5_child[5116 [become_user] (0x0200): 
> Trying to become user [657][100].
> (Mon Apr  3 10:45:20 2017) [[sssd[krb5_child[5116 [get_and_save_tgt] 
> (0x0020): 1302: [-1765328360][Preauthentication failed]
> (Mon Apr  3 10:45:20 2017) [[sssd[krb5_child[5116 [map_krb5_error] 
> (0x0020): 1371: [-1765328360][Preauthentication failed]
> (Mon Apr  3 10:45:20 2017) [[sssd[krb5_child[5116 [k5c_send_data] 
> (0x0200): Received error code 1432158221
> (Mon Apr  3 10:45:27 2017) [[sssd[krb5_child[5186 [switch_creds] 
> (0x0200): Switch user to [657][100].
> (Mon Apr  3 10:45:27 2017) [[sssd[krb5_child[5186 [switch_creds] 
> (0x0200): Switch user to [0][0].
> (Mon Apr  3 10:45:27 2017) [[sssd[krb5_child[5186 [check_fast_ccache] 
> (0x0200): FAST TGT is still valid.
> (Mon Apr  3 10:45:27 2017) [[sssd[krb5_child[5186 [become_user] (0x0200): 
> Trying to become user [657][100].
> (Mon Apr  3 10:45:28 2017) [[sssd[krb5_child[5186 [get_and_save_tgt] 
> (0x0020): 1302: [-1765328360][Preauthentication failed]
> (Mon Apr  3 10:45:28 2017) [[sssd[krb5_child[5186 [map_krb5_error] 
> (0x0020): 1371: [-1765328360][Preauthentication failed]
> (Mon Apr  3 10:45:28 2017) [[sssd[krb5_child[5186 [k5c_send_data] 
> (0x0200): Received error code 1432158221
> (Mon Apr  3 10:45:33 2017) [[sssd[krb5_child[5243 [switch_creds] 
> (0x0200): Switch user to [657][100].
> (Mon Apr  3 10:45:33 2017) [[sssd[krb5_child[5243 [switch_creds] 
> (0x0200): Switch user to [0][0].
> (Mon Apr  3 10:45:33 2017) [[sssd[krb5_child[5243 [check_fast_ccache] 
> (0x0200): FAST TGT is still valid.
> (Mon Apr  3 10:45:33 2017) [[sssd[krb5_child[5243 [become_user] (0x0200): 
> Trying to become user [657][100].
> (Mon Apr  3 10:45:33 2017) [[sssd[krb5_child[5243 [get_and_save_tgt] 
> (0x0020): 1302: [-1765328360][Preauthentication failed]
> (Mon Apr  3 10:45:33 2017) [[sssd[krb5_child[5243 [map_krb5_error] 
> (0x0020): 1371: [-1765328360][Preauthentication failed]
> (Mon Apr  3 10:45:33 2017) [[sssd[krb5_child[5243 [k5c_send_data] 
> (0x0200): Received error code 1432158221
> (Mon Apr  3 10:45:39 2017) [[sssd[krb5_child[5304 [switch_creds] 
> (0x0200): Switch user to [657][100].
> (Mon Apr  3 10:45:39 2017) [[sssd[krb5_child[5304 [switch_creds] 
> (0x0200): Switch user to [0][0].
> (Mon Apr  3 10:45:39 2017) [[sssd[krb5_child[5304 [check_fast_ccache] 
> (0x0200): FAST TGT is still valid.
> (Mon Apr  3 10:45:39 2017) [[sssd[krb5_child[5304 [become_user] (0x0200): 
> Trying to become user [657][100].
> (Mon Apr  3 10:45:39 2017) [[sssd[krb5_child[5304 [k5c_send_data] 
> (0x0200): Received error code 0

Please re-run with a higher log level. E.g. it would be good to know if
all requests where send to the same KDC or different ones?

If the requests were send to different KDCs it might be a time skew
issue, although I would expect a different error code here.

Do you have KDC logs for those requests?

bye,
Sumit

> 
> sssd_pam.log:
> 
> (Mon Apr  3 10:45:20 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): 
> Received client version [3].
> (Mon Apr  3 10:45:20 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): 
> Offered version [3].
> (Mon Apr  3 10:45:20 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): 
> name 'juppschmitz' matched without domain, user is juppschmitz
> (Mon Apr  3 10:45:20 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): 
> received: [8 (Insufficient credentials to access authentication 
> data)][example.com]
> (Mon Apr  3 10:45:20 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 
> with result [8]: Insufficient credentials to access authentication data.
> (Mon Apr  3 10:45:20 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 26
> (Mon Apr  3 10:45:22 2017) [sssd[pam]] [client_recv] (0x0200): Client 
> disconnected!
> (Mon Apr  3 10:45:27 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): 
> Received client version [3].
> (Mon Apr  3 10:45:27 2017) [sssd[pam]] [sss_cmd_get_version] (0x0200): 
> Offered version [3].
> (Mon Apr  3 10:45:27 2017) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): 
> name 'juppschmitz' matched without domain, user is juppschmitz
> (Mon Apr  3 10:45:28 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200): 
> received: [8 (Insufficient credentials to access authentication 
> data)][example.com]
> (Mon Apr  3 10:45:28 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply called 

Re: [Freeipa-users] RHEL 6.9 AD Smart Card login

[Sumit Bose]

On Tue, Apr 11, 2017 at 04:24:51PM +, spammewo...@cox.net wrote:
> I made the changes in this Bugzilla report and its still failing. When I
> click on Smartcard Authenication on the GDM login screen,   I get the error
> message "Authentication failure".It looks like this Bugzilla was for IDM
> users using smart cards. I'm trying to use Active Directory Users and
> smart cards.

Using IdM or AD shouldn't make a difference here. Did you change
/etc/pam.d/smartcart-auth according to comment #8 (similar changes are
needed on RHEL7 as well)? Please send the full SSSD logs, especially
sssd_pam.log, with debug_level=10 and /var/log/secure. Feel free to send
them to me directly if you do not want to share them on the list.

bye,
Sumit

> 
> Here is my error log from /var/log/sssd/p11_child.log
> (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893 [main] (0x0400):
> p11_child started.
> (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893 [main] (0x2000):
> Running in [pre-auth] mode.
> (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893 [main] (0x2000):
> Running with effective IDs: [0][0].
> (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893 [main] (0x2000):
> Running with real IDs [0][0].
> (Tue Apr 11 11:24:45 2017) [[sssd[p11_child[14893
> [parse_cert_verify_opts] (0x4000): Found 'no_ocsp' option, disabling OCSP.
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> Default Module List:
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> common name: [NSS Internal PKCS #11 Module].
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> dll name: [(null)].
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> common name: [CoolKey PKCS #11 Module].
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> dll name: [libcoolkeypk11.so].
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> Dead Module List:
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000): DB
> Module List:
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> common name: [NSS Internal Module].
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> dll name: [(null)].
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> common name: [Policy File].
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> dll name: [(null)].
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> Description [NSS User Private Key and Certificate Services Mozilla
> Foundation  ] Manufacturer [Mozilla Foundation ] flags [1].
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> Description [NSS Internal Cryptographic Services Mozilla Foundation
> ] Manufacturer [Mozilla Foundation ] flags [1].
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> Description [SCM SCR 3310 00 00 Unknown ]
> Manufacturer [Unknown ] flags [7].
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> Found [SMITH.RYAN.123456] in slot [SCM SCR 3310 00 00][1] of module [2].
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> Token is NOT friendly.
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> Trying to switch to friendly to read certificate.
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> Login required.
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x0020):
> Login required but no pin available, continue.
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> found cert[SMITH.RYAN.123456:PIV ID
> Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME]
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> found cert[SMITH.RYAN.123456:PIV Email Signature
> Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME]
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> found cert[SMITH.RYAN.123456:PIV Email Encryption
> Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME]
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> Filtered certificates:
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> found cert[SMITH.RYAN.123456:PIV ID
> Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME]
> (Tue Apr 11 11:24:46 2017) [[sssd[p11_child[14893 [do_work] (0x4000):
> found cert[SMITH.RYAN.123456:PIV Email Signature
> Certificate][CN=SMITH.RYAN.123456,OU=WORKER,OU=PKI,OU=HOME]
> (Tue Apr 11 11:24:46 2017) [[

Re: [Freeipa-users] Password-based authentication with AD users does not work

[Sumit Bose]

On Mon, Apr 10, 2017 at 11:49:05AM +0200, Ronald Wimmer wrote:
> On 2017-04-07 10:28, Sumit Bose wrote:
> > [...]
> > I'm not aware of any limitation here. Have you tried to run 'ipa
> > trust-fetch-domains ad.forest.root' to update the list?
> > 
> > If this does not help please add 'log level = 100' to
> > /usr/share/ipa/smb.conf.empty so that it looks like:
> > 
> >  [global]
> >  log level = 100
> > 
> > and run trust-fetch-domains again. The debug output can then be found
> > in /var/log/httpd/error_log. [...]
> 
> Not one error in the error_log - absolutely nothing. Our AD guys confirmed
> that there are many more UPN suffixes than the five I can see when I run ipa
> trust-find.
> 
> Can somebody confirm that this UPN suffix mismatch is exactly the problem
> preventing password-based login in my case?

To close the thread, it turned out that the original issue with
authenticating with enterprise principals is a bug which is now tracked
by https://bugzilla.redhat.com/show_bug.cgi?id=1441077.

bye,
Sumit

> 
> -- 
> 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] RHEL 6.9 AD Smart Card login

[Sumit Bose]

On Thu, Apr 06, 2017 at 06:36:43PM +, spammewo...@cox.net wrote:
> I have created a two way trust between my IDM server and Active Directory.
> I have been able to successful get RHEL 7.3 IDM server and RHEL 7.3 IDM
> clients to allow Active Directory login using CAC smart cards into Gnome.
> I'm using SSSD for the smart card login process instead of authconfig and
> pkcs11.   I'm currently trying to get the same thing working for RHEL 6.9,
> but I have not been able to get it to work. The latest version of SSSD on
> RHEL 6.9 is 1.13.3 and from my understanding I need to have at least 1.14.0
> for SSSD to handle AD smart card logins.So,  I have tried to configure

The Smartcard authentication feature was backported to RHEL-6.9.

Please note that the GDM Smartcard feature must be configured
differently in RHEL6 then in RHEL7, details for RHEL-6.9 can e.g. found
in https://bugzilla.redhat.com/show_bug.cgi?id=1300421#c13

HTH

bye,
Sumit

> pam_pkcs11.conf file to use the pwent mapper to link the Common Name (CN) to
> the Active Directory User account.   I have created an User ID Override for
> the AD user and  added CN name from the Certificate on the smart card into
> the GECOS field.   I also have added all three certificates from the CAC
> smart card into the User ID Override.
> 
> When I try and log in,  I get this error message in /var/log/secure:
> Apr  6 13:21:57 site-lws05 pam: gdm-smartcard:
> pam_pkcs11(gdm-smartcard:auth): pam_get_pwd() failed: Conversation error
> Apr  6 13:22:17 site-lws05 pam: gdm-smartcard:
> pam_pkcs11(gdm-smartcard:auth): find_user() failed:  on cert #1
> Apr  6 13:22:17 site-lws05 pam: gdm-smartcard:
> pam_pkcs11(gdm-smartcard:auth): find_user() failed:  on cert #2
> Apr  6 13:22:17 site-lws05 pam: gdm-smartcard:
> pam_pkcs11(gdm-smartcard:auth): no valid certificate which meets all
> requirements found
> 
> Here is the some details:
> IDM Domain: idm.domain.local
> Windows Domain: domain.local
> RHEL 7.3 IDM Server: site-idm01.idm.domain.local
> RHEL 6.9 IDM Client : site-lws05.idm.domain.local
> 
> When I run the getent command on local accounts and IDM accounts I get user
> details,  but when I run the command on AD accounts it doesn't find them.
> So,  I'm wondering if that's why its not finding the CN name in the GECOS
> field.I'm trying to avoid using the cn_map on the clients, because we
> have a large amount of users and thats alot of extra work to manage that
> file.That's why I wanted to use the pwent mapper.
> Here is my SSSD config file from the RHEL 6.9 client:
> [domain/idm.domain.local]
> override_shell = /bin/bash
> debug_level = 9
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = idm.domain.local
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = site-lws05.idm.domain.local
> chpass_provider = ipa
> ipa_server = _srv_, site-idm01.idm.domain.local
> ldap_tls_cacert = /etc/ipa/ca.crt
> [sssd]
> debug_level = 9
> services = nss, sudo, pam, ssh, ifp
> domains = idm.domain.local
> certificate_verification = no_ocsp
> ldap_user_certificate = userCertificate;binary
> [nss]
> debug_level = 9
> homedir_substring = /home
> [pam]
> debug_level = 9
> pam_cert_auth = True
> [sudo]
> debug_level = 9
> [autofs]
> debug_level = 9
> [ssh]
> debug_level = 9
> [pac]
> debug_level = 9
> [ifp]
> debug_level = 9
> 
> Here is my nssswitch file from the RHEL 6.9 client:
> # /etc/nsswitch.conf
> #
> # An example Name Service Switch config file. This file should be
> # sorted with the most-used services at the beginning.
> #
> # The entry '[NOTFOUND=return]' means that the search for an
> # entry should stop if the search in the previous entry turned
> # up nothing. Note that if the search failed due to some other reason
> # (like no NIS server responding) then the search continues with the
> # next entry.
> #
> # Valid entries include:
> #
> #   nisplus Use NIS+ (NIS version 3)
> #   nis Use NIS (NIS version 2), also called YP
> #   dns Use DNS (Domain Name Service)
> #   files   Use the local files
> #   db  Use the local database (.db) files
> #   compat  Use NIS on compat mode
> #   hesiod  Use Hesiod for user lookups
> #   [NOTFOUND=return]   Stop searching if not found so far
> #
> # To use db, put the "db" in front of "files" for entries you want to be
> # looked up first in the databases
> #
> # Example:
> #passwd:db files nisplus nis
> #shadow:db files nisplus nis
> #group: db files nisplus nis
> passwd: files sss
> shadow: files sss
> group:  files sss
> #hosts: db files nisplus nis dns
> hosts:  files dns
> # Example - obey only what nisplus tells us...
> #services:   nisplus [NOTFOUND=return] files
> #networks:   nisplus [NOTFOUND=return] files
> #protocols:  nisplus [NOTFOUND=return] files
> #rpc:  

Re: [Freeipa-users] Password-based authentication with AD users does not work

[Sumit Bose]

On Fri, Apr 07, 2017 at 09:46:45AM +0200, Ronald Wimmer wrote:
> On 2017-04-06 20:50, Sumit Bose wrote:
> > On Thu, Apr 06, 2017 at 01:55:02PM +0200, Ronald Wimmer wrote:
> > > On 2017-04-06 12:16, Sumit Bose wrote:
> > > > On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote:
> > > > [...]
> > > > > AD trust:
> > > > > mydomain.at (forest root)
> > > > > xyz (subdomain -> where myuser resides)
> > > > > 
> > > > > BCC (appearing in krb5_child.log) is not a domain here. It is my 
> > > > > company's
> > > > > name and might derive from some information in the AD.
> > > > Yes, it is about the userPrincipalName attribute read from AD. Which IPA
> > > > server version do you use? Since RHEL-7.3 IPA supports those principals
> > > > coming from AD. For older versions you should add a workaround which is
> > > > e.g. described at the end of
> > > > https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html
> > > > 
> > > > HTH
> > > > 
> > > > bye,
> > > > Sumit
> > > 
> > > I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to
> > > override it?
> > 
> > Please check on the server with
> > 
> > ipa trust-find
> > 
> > if the BCC domain is listed as 'UPN suffixes:'. If not please try
> > 
> > ipa trust-fetch-domains
> > 
> > and check again. If the domain is listed then a 7.3 IPA client should be
> > able to detect it automatically on older clients you should set
> > 'krb5_use_enterprise_principal = True' manually in sssd.conf.
> 
> I just checked with our AD guys. ipa trust-find only shows five UPN
> suffixes. There are many more which are not shown inlcuding bcc.mydomain.at
> 
> Any idea why only a subset is shown?

I'm not aware of any limitation here. Have you tried to run 'ipa
trust-fetch-domains ad.forest.root' to update the list?

If this does not help please add 'log level = 100' to
/usr/share/ipa/smb.conf.empty so that it looks like:

[global]
log level = 100

and run trust-fetch-domains again. The debug output can then be found
in /var/log/httpd/error_log. The logs might contain data which should
not be shared publicly, so feel free to send them to me directly.

bye,
Sumit

> 
> -- 
> 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] Password-based authentication with AD users does not work

[Sumit Bose]

On Thu, Apr 06, 2017 at 01:55:02PM +0200, Ronald Wimmer wrote:
> On 2017-04-06 12:16, Sumit Bose wrote:
> > On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote:
> > [...]
> > > AD trust:
> > > mydomain.at (forest root)
> > > xyz (subdomain -> where myuser resides)
> > > 
> > > BCC (appearing in krb5_child.log) is not a domain here. It is my company's
> > > name and might derive from some information in the AD.
> > Yes, it is about the userPrincipalName attribute read from AD. Which IPA
> > server version do you use? Since RHEL-7.3 IPA supports those principals
> > coming from AD. For older versions you should add a workaround which is
> > e.g. described at the end of
> > https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html
> > 
> > HTH
> > 
> > bye,
> > Sumit
> 
> I am using an up-to-date RHEL 7.3 IPA master. Is there no possibility to
> override it?

Please check on the server with

ipa trust-find

if the BCC domain is listed as 'UPN suffixes:'. If not please try

ipa trust-fetch-domains

and check again. If the domain is listed then a 7.3 IPA client should be
able to detect it automatically on older clients you should set
'krb5_use_enterprise_principal = True' manually in sssd.conf.

HTH

bye,
Sumit

> 
> 
> -- 
> 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] Password-based authentication with AD users does not work

[Sumit Bose]

On Thu, Apr 06, 2017 at 12:58:32PM +0200, Ronald Wimmer wrote:
> On 2017-04-06 11:21, Sumit Bose wrote:
> > On Thu, Apr 06, 2017 at 12:10:29PM +0200, Ronald Wimmer wrote:
> > > Hi,
> > > 
> > > when I try to login to an IPA client with my AD user it works perfectly 
> > > when
> > > I already have a kerberos ticket for my user. When I do not and I try a
> > > password-based login it fails:
> > Please send the sssd_domain.log and krb5_child.log form the same time as
> > well.
> > 
> 
> AD trust:
> mydomain.at (forest root)
> xyz (subdomain -> where myuser resides)
> 
> BCC (appearing in krb5_child.log) is not a domain here. It is my company's
> name and might derive from some information in the AD.

Yes, it is about the userPrincipalName attribute read from AD. Which IPA
server version do you use? Since RHEL-7.3 IPA supports those principals
coming from AD. For older versions you should add a workaround which is
e.g. described at the end of
https://www.redhat.com/archives/freeipa-users/2016-November/msg00069.html

HTH

bye,
Sumit

-- 
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] Password-based authentication with AD users does not work

[Sumit Bose]

On Thu, Apr 06, 2017 at 12:10:29PM +0200, Ronald Wimmer wrote:
> Hi,
> 
> when I try to login to an IPA client with my AD user it works perfectly when
> I already have a kerberos ticket for my user. When I do not and I try a
> password-based login it fails:

Please send the sssd_domain.log and krb5_child.log form the same time as
well.

bye,
Sumit

> 
> Password-based:
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_check_user_search] (0x0400):
> Returning info for user [myu...@xyz.mydomain.at@xyz.mydomain.at]
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pd_set_primary_name] (0x0400):
> User's primary name is myu...@xyz.mydomain.at
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending
> request with the following data:
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): command:
> SSS_PAM_PREAUTH
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): domain:
> XYZ
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): user:
> myu...@xyz.mydomain.at
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): service:
> sshd
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not
> set
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost:
> chupacabra.ipa.mydomain.at
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok
> type: 0
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok
> type: 0
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid:
> 31816
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_print_data] (0x0100): logon
> name: myuser
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [sbus_add_timeout] (0x2000):
> 0x7f4c122ed450
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100):
> pam_dp_send_req returned 0
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [sbus_remove_timeout] (0x2000):
> 0x7f4c122ed450
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn:
> 0x7f4c122e59c0
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [sbus_dispatch] (0x4000):
> Dispatching.
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200):
> received: [4 (System error)][XYZ]
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply
> called with result [4]: System error.
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 20
> (Thu Apr  6 10:39:12 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle
> timer re-set for client [0x7f4c122f4640][21]
> 
> When I have a Kerberos ticket:
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_check_user_search] (0x0400):
> Returning info for user [myu...@xyz.mydomain.at@xyz.mydomain.at]
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pd_set_primary_name] (0x0400):
> User's primary name is myu...@xyz.mydomain.at
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending
> request with the following data:
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): command:
> SSS_PAM_OPEN_SESSION
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): domain:
> XYZ
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): user:
> myu...@xyz.mydomain.at
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): service:
> sshd
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): ruser: not
> set
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): rhost:
> chupacabra.ipa.mydomain.at
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): authtok
> type: 0
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): newauthtok
> type: 0
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): priv: 1
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): cli_pid:
> 31841
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_print_data] (0x0100): logon
> name: myuser
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [sbus_add_timeout] (0x2000):
> 0x7f4c122ec4a0
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_dom_forwarder] (0x0100):
> pam_dp_send_req returned 0
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [sbus_remove_timeout] (0x2000):
> 0x7f4c122ec4a0
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn:
> 0x7f4c122e59c0
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [sbus_dispatch] (0x4000):
> Dispatching.
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_dp_process_reply] (0x0200):
> received: [0 (Success)][XYZ]
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_reply] (0x0200): pam_reply
> called with result [0]: Success.
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [pam_reply] (0x0200): blen: 20
> (Thu Apr  6 10:41:00 2017) [sssd[pam]] [reset_idle_timer] (0x4000): Idle
> timer re-set for client [0x7f4c122f4640][21]
> 

Re: [Freeipa-users] Certificate Access issue

[Sumit Bose]

On Mon, Mar 20, 2017 at 02:55:37PM +0300, Artem Golubev wrote:
> Good day!
> 
> We use freeipa server 4.3.1, we usually grant access via ssh keys to linux
> clients.
> We currently face the following issue with access on certificate: when we
> add certificate to user's account, user is not able to login via ssh.
> How can we solve this problem? We would like to have  a possibility to
> access linux clients via ssh keys and access to other resources using
> certificates.

I guess this is https://pagure.io/SSSD/sssd/issue/2977 which should be
fixed in recent version of SSSD. Which version of SSSD are you using and
which platform/OS?

HTH

bye,
Sumit

> 
> Hope to receive a reply from you soon.
> Best regards.
> *​*
> 
> *​Artem Golubev*
> System Administrator
> *(exp)capital limited*

> -- 
> 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] Fedora 25 IPA smart card login

[Sumit Bose]

On Tue, Mar 14, 2017 at 04:29:58PM -0500, Michael Rainey (Contractor) wrote:
> Greetings,
> 
> I have been working on an issue with smart card logins on a Fedora 25
> system.  For a short time smart card logins have been working well, but
> suddenly the login process has suddenly stopped working.  I have verified
> that all appropriate certificates are installed, checked my dconf
> configuration, checked my PAM files, and reviewed the logs.  I have noticed
> a few issues, but changing them to match my SL7 systems did not resolve the
> problem.

At the first glance the config files are looking good.

Please send /var/log/secure or the PAM related journal data and the SSSD
logs files with debug_level=10. If you prefer you can send them directly
to me.

bye,
Sumit

> 
> My observation has been with my PAM files and authconfig.  I have noticed
> that when an update occurs, authconfig will run changing my PAM files.  Has
> IPA been integrated with authconfig or do I still need to keep the options
> in authconfig largely disabled and manually modify my PAM files?
> 
> System Information:
> 
> 
> Package:
> freeipa-client.x86_644.4.3-2.fc25
> 
> PAM:
> -
> smartcard-auth-ac
> -
> authrequired  pam_env.so
> authsufficientpam_sss.so allow_missing_name
> authrequired  pam_deny.so
> 
> account required  pam_unix.so
> account sufficientpam_localuser.so
> account sufficientpam_succeed_if.so uid < 1000 quiet
> account [default=bad success=ok user_unknown=ignore] pam_sss.so
> account required  pam_permit.so
> 
> 
> session optional  pam_keyinit.so revoke
> session required  pam_limits.so
> -session optional  pam_systemd.so
> session [success=1 default=ignore] pam_succeed_if.so service in crond
> quiet use_uid
> session required  pam_unix.so
> session optional  pam_sss.so
> 
> -
> password-auth-ac
> -
> authrequired  pam_env.so
> auth[default=1 success=ok] pam_localuser.so
> auth[success=done ignore=ignore default=die] pam_unix.so nullok
> try_first_pass
> authrequisite pam_succeed_if.so uid >= 1000 quiet_success
> authsufficientpam_sss.so forward_pass
> authrequired  pam_deny.so
> 
> account required  pam_unix.so
> account sufficientpam_localuser.so
> account sufficientpam_succeed_if.so uid < 1000 quiet
> account [default=bad success=ok user_unknown=ignore] pam_sss.so
> account required  pam_permit.so
> 
> passwordrequisite pam_pwquality.so try_first_pass local_users_only
> retry=3 authtok_type=
> passwordsufficientpam_unix.so sha512 shadow nullok try_first_pass
> use_authtok
> passwordsufficientpam_sss.so use_authtok
> passwordrequired  pam_deny.so
> 
> session optional  pam_keyinit.so revoke
> session required  pam_limits.so
> -session optional  pam_systemd.so
> session [success=1 default=ignore] pam_succeed_if.so service in crond
> quiet use_uid
> session required  pam_unix.so
> session optional  pam_sss.so
> 
> -
> DCONF: org.gnome.login-screen
> -
> org.gnome.login-screen fallback-logo ''
> org.gnome.login-screen disable-user-list false
> org.gnome.login-screen allowed-failures 3
> org.gnome.login-screen enable-smartcard-authentication true
> org.gnome.login-screen banner-message-enable false
> org.gnome.login-screen enable-password-authentication true
> org.gnome.login-screen disable-restart-buttons false
> org.gnome.login-screen logo '/usr/share/pixmaps/fedora-gdm-logo.png'
> org.gnome.login-screen enable-fingerprint-authentication true
> org.gnome.login-screen banner-message-text ''
> 
> -- 
> *Michael Rainey*
> Network Representative
> Naval Research Latoratory, Code 7320
> Building 1009, Room C156
> Stennis Space Center, MS 39529
> 

> -- 
> 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] Katello IPA auth and Cross realm trust.

[Sumit Bose]

On Wed, Feb 22, 2017 at 12:03:58PM +, wouter.hummel...@kpn.com wrote:
> Hello all,
> 
> I'm trying to get IPA auth on Katello to work properly, however the infopipe 
> is unable to access the right information without additional configuration.
> With these changes I got the infopipe to work, but then user logins started 
> to fail due to invalid user errors.
> 
> I've added the following to the domain/xxx section on the katello server
> 
> [domain/XXX]
> ldap_user_extra_attrs=email:mail, lastname:sn, firstname:givenname

Current version of SSSD already read the email attribute from the server
(check ldap_user_email in man sssd-ldap). So you can either remove email
from your ldap_user_extra_attrs or set 'ldap_user_email = noSuchAttr' to
avoid the collision.

HTH

bye,
Sumit

> 
> [ifp]
> 
> allowed_uids=apache, root
> user_attributes=+email, +firstname, +lastname
> 
> 
> And on the ipa server:
> [nss]
> user_attributes=+mail, +sn, +givenname
> 
> [domain/XXX]
> ldap_user_extra_attrs=mail, sn, givenname
> 
> However, the suggested change on the IPA server (from the satellite 
> installation guide) results in user lookup failures on client systems (not 
> exclusive to the katello host)
> 
> # id user@TRUSTED.DOMAIN
> id: user@TRUSTED.DOMAIN: no such user
> 
> SSSD logs do reveal a hint about whats going on:
> [filtered for brevity, modified for privacy]
> (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [sdap_get_generic_ext_step] 
> (0x0400): calling ldap_search_ext with 
> [(&(|(krbPrincipalName=user@TRUSTED.DOMAIN)(mail=user@TRUSTED.DOMAIN)(krbPrincipalName=user\\@TRUSTED.DOMAIN@IPA.DOMAIN))(objectclass=posixAccount)(uid=*)(&(uidNumber=*)(!(uidNumber=0][cn=accounts,dc=linux,dc=infra,dc=local].
> (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [sdap_get_generic_ext_step] 
> (0x1000): Requesting attrs: [mail]
> (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [get_extra_attrs] (0x4000): 
> Extra attribute [mail].
> (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [get_extra_attrs] (0x4000): 
> Extra attribute [mail].
> (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [get_extra_attrs] (0x4000): 
> Extra attribute [mail].
> (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [get_extra_attrs] (0x4000): 
> Extra attribute [mail].
> (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [is_email_from_domain] 
> (0x4000): Email [sander.lambrec...@kpn.com] is not from domain 
> [TRUSTED.DOMAIN].
> (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] [is_email_from_domain] 
> (0x4000): Email [sander.lambrec...@kpn.com] is not from domain 
> [TRUSTED.DOMAIN].
> (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] 
> [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [Attribute or value 
> exists](20)[attribute 'mail': value #1 on 
> 'name=user@TRUSTED.DOMAIN,cn=users,cn=TRUSTED.DOMAIN,cn=sysdb' provided more 
> than once]
> (Wed Feb 22 11:51:20 2017) [sssd[be[IPA.DOMAIN]]] 
> [sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [Attribute or value 
> exists](20)[attribute 'mail': value #1 on 
> 'name=user@TRUSTED.DOMAIN,cn=users,cn=TRUSTED.DOMAIN,cn=sysdb' provided more 
> than once]
> 
> Am I running into a bug or have I misconfigured this somewhere?
> 
> Met vriendelijke groet,
> Wouter Hummelink
> Technical Consultant - Enterprise Webhosting
> T: +31-6-12882447
> E: wouter.hummel...@kpn.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] ipa- client rhel 6.9 support for UPN different then domain name

[Sumit Bose]

On Wed, Feb 08, 2017 at 12:44:07PM +0100, Troels Hansen wrote:
> Hi, 
> 
> Have you tried setting ldap_user_principal to something nonexisting? For 
> example:
> 
> ldap_user_principal = nosuchattr
> 
> and inherit this to the AD domain with:
> 
> subdomain_inherit = ldap_user_principal
> 
> Both in the domain section of sssd.

Enterprise principals are supported by IPA since RHEL 7.3, so this
work-around for older versions should not be needed anymore.

> 
> - On Feb 8, 2017, at 12:17 PM, Jan Karásek jan.kara...@elostech.cz wrote:
> 
> > Hi, thank you for help.
> > 
> > I am running RHEL 7.3 on IPA serveres and with RHEL 7.3 clients it works 
> > really
> > nice.
> > Trouble is on RHEL 6 machines. I have tried to add 
> > krb5_use_enterprise_principal
> > = true into domain section of sssd.conf on RHEL 6 IPA clients but problem 
> > still
> > persists. Is there anything else that should be set ?  I have restarted sssd
> > service, both on servers and client, empty sssd_cache and so on but I am 
> > still
> > unable resolve users(on RHEL 6) with short UPN - id and getent passwd 
> > return no
> > such user...We still have more servers on RHEL 6 then on RHEL 7.

SSSD logs from a RHEL 6 client which includes a failing user lookup are
needed to see why it is still failing, see
https://fedorahosted.org/sssd/wiki/Troubleshooting for details.

bye,
Sumit

> > 
> > Thanks,
> > Jan
> > 
> > 
> >> Hi,
> >> 
> >> I just looked into RHEL 6.9 beta repos and I can see there is
> >> sssd-client-1.13.3-53.el6.x86_64 version. I would like to know if with 
> >> rhel 6.9
> >> will come support for using different UPN then domain name. I am talking 
> >> about
> >> AD trust scenario where user in AD domain sits in 
> >> u...@subdomain.example.com
> >> but has a UPN set to u...@example.com. It has been solved in RHEL 7.3 I 
> >> guess
> >> with sssd 1.14. Is ipa-client in RHEL 6.9 able to handle this situation or 
> >> is
> >> there any known workaround ?
> > 
> > This is basically a server side feature. You need an IPA server version
> > which is delivered with RHEL-7.3. SSSD 1.14 in 7.3 can automatically
> > detect if the server supports this or not. This autodetection was not
> > backported to 6.9 but if your servers support it you can set
> > 'krb5_use_enterprise_principal = true' (see man sssd-krb5 for details)
> > on the IPA clients with older SSSD versions.
> > 
> > HTH
> > 
> > bye,
> > Sumit
> > 
> >> 
> >> Thanks,
> >> Jan
> >> 
> > 
> > 
> > --
> > 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
> 
> -- 
> 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

-- 
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] Smart Card login into an Active Directory User

[Sumit Bose]

On Fri, Feb 03, 2017 at 12:59:26PM -0800, spammewo...@cox.net wrote:
> 
>  Sumit Bose <sb...@redhat.com> wrote: 
> > On Fri, Feb 03, 2017 at 09:33:13AM +0100, Sumit Bose wrote:
> > On Thu, Feb 02, 2017 at 11:03:28AM -0800, spammewo...@cox.net wrote:
> > > I am running an IPA server (4.4.0) on RHEL 7.3 which is integrated with a 
> > > Windows Active Directory server.   I am trying to configure the IPA 
> > > server to allow the Active Directory Users to log into Gnome with a CAC 
> > > smart card.  I’m having a hard time finding any instructions on how to do 
> > > this.  The problem I’m having is the Common Name from the smart card is 
> > > not getting associated with the Active Directory account.  I added the 
> > > certificate from the smart card to the IPA server by creating a User ID 
> > > override for the AD user account.  I made sure to not use authconfig to 
> > > configure smart cards and I added ifp to the services line in the 
> > > sssd.conf file.
> > > 
> > > I have the following packages installed:
> > > ipa-admintools.noarch   4.4.0-14.el7_3.4  
> > >   
> > > ipa-client.x86_64   4.4.0-14.el7_3.4  
> > >   
> > > ipa-client-common.noarch   4.4.0-14.el7_3.4   
> > > 
> > > ipa-common.noarch   4.4.0-14.el7_3.4  
> > > 
> > > ipa-python-compat.noarch   4.4.0-14.el7_3.4   
> > >   
> > > ipa-server.x86_64   4.4.0-14.el7_3.4  
> > >   
> > > ipa-server-common.noarch   4.4.0-14.el7_3.4   
> > >   
> > > ipa-server-dns.noarch  4.4.0-14.el7_3.4
> > > ipa-server-trust-ad.x86_64  4.4.0-14.el7_3.4
> > > 
> > > I can log in with AD user accounts that are configured with UserName and 
> > > Passswords, so I know that the integration is working.   When I try to 
> > > log into GDM with my smart card,  I don’t get prompted for a PIN number.  
> > > It only asks for the password from the AD account.   
> > 
> > Please have a look at the steps described in
> > https://bugzilla.redhat.com/show_bug.cgi?id=1300420#c9 . Please let me
> > know if you run into issues.
> 
> Please also check if you followed the steps in
> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/smart-cards.html
> 
> HTH
> 
> bye,
> Sumit
> 
> -- 
> Hello Sumit,
> I followed the instructions in comment #9.I modified the 
> /etc/pam.d/smartcard-auth file and the two files that are under 
> /etc/dconf/db/distro.d/.   But it still doesn't work.   GDM will prompt me 
> for a password not the PIN when I plug in the smart card.Do I need to run 
> "authconfig --enablesmartcard --smartcardmodule=no_module --update" before I 
> change the files ?Should I remove pam_pkcs11 too ?I have been able to 
> get AD smart card login working using standard authconfig, pam_pkcs11, and 
> the cn_map.I just don't want to use the cn_map file and have to list all 
> of my user's "Common Names" in this file.

With the steps you described running authconfig is not needed and might
even do more harm than good. I think it would be best check the SSSD
logs next.

Please add 'debug_level = 9' at least to the [pam] section of sssd.conf
and restart SSSD (see https://fedorahosted.org/sssd/wiki/Troubleshooting
for details). Now try to authenticate again. The relevant log files are
/var/log/sssd/sssd_pam.log and /var/log/sssd/p11_child.log. The latter
e.g. should show if there are any issues validation the certificate.

Feel free to send the logs file to me directly if you do not want to
share them on a public list.

HTH

bye,
Sumit

> 
> 
> -- 
> 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] Ubuntu client 2FA not working

[Sumit Bose]

On Mon, Feb 06, 2017 at 01:56:06PM +, Tommy Nikjoo wrote:
> Hi,
> 
> I'm having some issues with 2FA PAM config's on Ubuntu clients. 
> Currently, I'm guessing that the PAM module doesn't know how to talk to
> the 2FA protocol.  Is anyone able to give an in site into how to get
> this working correctly?

In general you have to make sure the pam_sss is the pam modules which
does the conversation with the user and not e.g. pam_unix because
pam_unix will only ask for a password.

E.g. on Fedora/RHEL a general auth part of the PAM configuration might
look like:

authrequired  pam_env.so
auth[default=1 success=ok] pam_localuser.so
auth[success=done ignore=ignore default=die] pam_unix.so nullok 
try_first_pass
authrequisite pam_succeed_if.so uid >= 1000 quiet_success
authsufficientpam_sss.so forward_pass
authrequired  pam_deny.so

The pam_localuser module checks if the user trying to log in is a local
user, i.e. listed in /etc/passwd, and if it is a local user (success=ok)
the next module pam_unix is called. For non-local user the next module
is skipped (default=1) and after the uid check pam_sss is call which now
can prompt the user according to the authentication methods available
for the user on the IPA server.

HTH

bye,
Sumit

> 
> Thanks
> 
> **
> 
>   //
> 
> 
> 
> On 14/12/16 22:48, Fraser Tweedale wrote:
> > On Wed, Dec 14, 2016 at 05:35:35PM +, Tommy Nikjoo wrote:
> >> Hi,
> >>
> >> I'm trying to install FreeIPA on CentOS 7 using the yum package, but I
> >> keep getting an error when it tries to restart DogTag
> >>
> >>   [26/31]: restarting certificate server
> >> ipa.ipaserver.install.cainstance.CAInstance: CRITICAL Failed to restart
> >> the Dogtag instance.See the installation log for details.
> >>   [27/31]: migrating certificate profiles to LDAP
> >>   [error] NetworkError: cannot connect to
> >> 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': ''
> >> ipa.ipapython.install.cli.install_tool(Server): ERRORcannot connect
> >> to 'https://ldap2.armourcomms.com:8443/ca/rest/account/login': ''
> >> ipa.ipapython.install.cli.install_tool(Server): ERRORThe
> >> ipa-server-install command failed. See /var/log/ipaserver-install.log
> >> for more information
> >>
> >>
> >> The log shows the following error
> >>
> >> 2016-12-14T16:53:05Z DEBUG NSSConnection init ldap.example.com
> >> 2016-12-14T16:53:05Z DEBUG Connecting: x.x.x.x:0
> >> 2016-12-14T16:53:05Z DEBUG approved_usage = SSL Server intended_usage =
> >> SSL Server
> >> 2016-12-14T16:53:05Z DEBUG cert valid True for
> >> "CN=ldap.example.com,O=EXAMPLE.COM"
> >> 2016-12-14T16:53:05Z DEBUG handshake complete, peer = x.x.x.x:8443
> >> 2016-12-14T16:53:05Z DEBUG Protocol: TLS1.2
> >> 2016-12-14T16:53:05Z DEBUG Cipher: TLS_RSA_WITH_AES_256_CBC_SHA
> >> 2016-12-14T16:53:05Z DEBUG response status 200
> >> 2016-12-14T16:53:05Z DEBUG response headers {'content-length': '205',
> >> 'set-cookie': 'JSESSIONID=9B6C767CDBED07088646235E68E831E0; Path=/ca/;
> >> Secure; HttpOnly', 'expires': 'Thu, 01 Jan 1970 00:00:00 UTC', 'server':
> >> 'Apache-Coyote/1.1', 'cache-control': 'private', 'date': 'Wed, 14 Dec
> >> 2016 16:53:05 GMT', 'content-type': 'application/xml'}
> >> 2016-12-14T16:53:05Z DEBUG response body ' >> encoding="UTF-8" standalone="yes"?> >> id="ipara">iparaCertificate Manager
> >> AgentsRegistration Manager Agents'
> >> 2016-12-14T16:53:05Z DEBUG request POST
> >> https://ldap.example.com:8443/ca/rest/profiles/raw
> >> 2016-12-14T16:53:05Z DEBUG request body
> >> 'profileId=IECUserRoles\nclassId=caEnrollImpl\ndesc=Enroll user
> >> certificates with IECUserRoles extension via IPA-RA agent
> >> authentication.\nvisible=false\nenable=true\nenableBy=admin\nauth.instance_id=raCertAuth\nname=IPA-RA
> >> Agent-Authenticated Server Certificate
> >> Enrollment\ninput.list=i1,i2\ninput.i1.class_id=certReqInputImpl\ninput.i2.class_id=submitterInfoInputImpl\noutput.list=o1\noutput.o1.class_id=certOutputImpl\npolicyset.list=serverCertSet\npolicyset.serverCertSet.list=1,2,3,4,5,6,7,8,9,10,11,12\npolicyset.serverCertSet.1.constraint.class_id=subjectNameConstraintImpl\npolicyset.serverCertSet.1.constraint.name=Subject
> >> Name
> >> Constraint\npolicyset.serverCertSet.1.constraint.params.pattern=CN=[^,]+,.+\npolicyset.serverCertSet.1.constraint.params.accept=true\npolicyset.serverCertSet.1.default.class_id=subjectNameDefaultImpl\npolicyset.serverCertSet.1.default.name=Subject
> >> Name
> >> Default\npolicyset.serverCertSet.1.default.params.name=CN=$request.req_subject_name.cn$,
> >> O=EXAMPLE.COM\npolicyset.serverCertSet.2.constraint.class_id=validityConstraintImpl\npolicyset.serverCertSet.2.constraint.name=Validity
> >> 

Re: [Freeipa-users] Smart Card login into an Active Directory User

[Sumit Bose]

On Fri, Feb 03, 2017 at 09:33:13AM +0100, Sumit Bose wrote:
> On Thu, Feb 02, 2017 at 11:03:28AM -0800, spammewo...@cox.net wrote:
> > I am running an IPA server (4.4.0) on RHEL 7.3 which is integrated with a 
> > Windows Active Directory server.   I am trying to configure the IPA server 
> > to allow the Active Directory Users to log into Gnome with a CAC smart 
> > card.  I’m having a hard time finding any instructions on how to do this.  
> > The problem I’m having is the Common Name from the smart card is not 
> > getting associated with the Active Directory account.  I added the 
> > certificate from the smart card to the IPA server by creating a User ID 
> > override for the AD user account.  I made sure to not use authconfig to 
> > configure smart cards and I added ifp to the services line in the sssd.conf 
> > file.
> > 
> > I have the following packages installed:
> > ipa-admintools.noarch   4.4.0-14.el7_3.4
> > 
> > ipa-client.x86_64   4.4.0-14.el7_3.4
> > 
> > ipa-client-common.noarch   4.4.0-14.el7_3.4 
> >   
> > ipa-common.noarch   4.4.0-14.el7_3.4
> >   
> > ipa-python-compat.noarch   4.4.0-14.el7_3.4 
> > 
> > ipa-server.x86_64   4.4.0-14.el7_3.4
> > 
> > ipa-server-common.noarch   4.4.0-14.el7_3.4 
> > 
> > ipa-server-dns.noarch  4.4.0-14.el7_3.4
> > ipa-server-trust-ad.x86_64  4.4.0-14.el7_3.4
> > 
> > I can log in with AD user accounts that are configured with UserName and 
> > Passswords, so I know that the integration is working.   When I try to log 
> > into GDM with my smart card,  I don’t get prompted for a PIN number.  It 
> > only asks for the password from the AD account.   
> 
> Please have a look at the steps described in
> https://bugzilla.redhat.com/show_bug.cgi?id=1300420#c9 . Please let me
> know if you run into issues.

Please also check if you followed the steps in
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/smart-cards.html

HTH

bye,
Sumit

-- 
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] Smart Card login into an Active Directory User

[Sumit Bose]

On Thu, Feb 02, 2017 at 11:03:28AM -0800, spammewo...@cox.net wrote:
> I am running an IPA server (4.4.0) on RHEL 7.3 which is integrated with a 
> Windows Active Directory server.   I am trying to configure the IPA server to 
> allow the Active Directory Users to log into Gnome with a CAC smart card.  
> I’m having a hard time finding any instructions on how to do this.  The 
> problem I’m having is the Common Name from the smart card is not getting 
> associated with the Active Directory account.  I added the certificate from 
> the smart card to the IPA server by creating a User ID override for the AD 
> user account.  I made sure to not use authconfig to configure smart cards and 
> I added ifp to the services line in the sssd.conf file.
> 
> I have the following packages installed:
> ipa-admintools.noarch   4.4.0-14.el7_3.4  
>   
> ipa-client.x86_64   4.4.0-14.el7_3.4  
>   
> ipa-client-common.noarch   4.4.0-14.el7_3.4   
> 
> ipa-common.noarch   4.4.0-14.el7_3.4  
> 
> ipa-python-compat.noarch   4.4.0-14.el7_3.4   
>   
> ipa-server.x86_64   4.4.0-14.el7_3.4  
>   
> ipa-server-common.noarch   4.4.0-14.el7_3.4   
>   
> ipa-server-dns.noarch  4.4.0-14.el7_3.4
> ipa-server-trust-ad.x86_64  4.4.0-14.el7_3.4
> 
> I can log in with AD user accounts that are configured with UserName and 
> Passswords, so I know that the integration is working.   When I try to log 
> into GDM with my smart card,  I don’t get prompted for a PIN number.  It only 
> asks for the password from the AD account.   

Please have a look at the steps described in
https://bugzilla.redhat.com/show_bug.cgi?id=1300420#c9 . Please let me
know if you run into issues.

HTH

bye,
Sumit

> 
> 
> -- 
> 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] ipa- client rhel 6.9 support for UPN different then domain name

[Sumit Bose]

On Thu, Feb 02, 2017 at 04:57:05PM +0100, Jan Karásek wrote:
> Hi,
> 
> I just looked into RHEL 6.9 beta repos and I can see there is 
> sssd-client-1.13.3-53.el6.x86_64 version. I would like to know if with rhel 
> 6.9 will come support for using different UPN then domain name. I am talking 
> about AD trust scenario where user in AD domain sits in 
> u...@subdomain.example.com but has a UPN set to u...@example.com. It has been 
> solved in RHEL 7.3 I guess with sssd 1.14. Is ipa-client in RHEL 6.9 able to 
> handle this situation or is there any known workaround ?

This is basically a server side feature. You need an IPA server version
which is delivered with RHEL-7.3. SSSD 1.14 in 7.3 can automatically
detect if the server supports this or not. This autodetection was not
backported to 6.9 but if your servers support it you can set
'krb5_use_enterprise_principal = true' (see man sssd-krb5 for details)
on the IPA clients with older SSSD versions. 

HTH

bye,
Sumit

> 
> Thanks,
> Jan 
> 
> -- 
> 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] [SOLVED] Re: guidance on SID-UID mapping via sssd-ad -- one child domain works fine, 2nd domain generating SID-to-UID mapping error

[Sumit Bose]

On Wed, Feb 01, 2017 at 02:41:35PM -0500, Chris Dagdigian wrote:
> 
> Update:
> 
> Resolved.  A bit of googling led me to some good RHEL pages as well as
> mailing list messages from Alex B that were concise and helpful.
> 
> To summarize for others who may have this problem:
> 
> 1. Don't make changes to sssd.conf if your provider is "ipa" - in this case
> you work only with "ipa idrange-mod" type commands or webUI
> 
> 2. The simple solution is to increase the range and restart SSSD after
> blowing away out of date sssd  database:
> 
> # ipa idrange-mod --base-id=400 --range-size=100
> EAME.COMPANY.ORG_id_range
> # service sssd stop; rm -f /var/lib/sss/db/*; service sssd start
> 
> 
> What I actually did on our IPA server was a bit more expansive. EAME was the
> first child domain where I had the SID to UID map issue but it would
> probably not have been the only one so I figured it would be safer to make
> sure that every child domain range had at least 1 million available IDs
> 
> Using the IPA webUI under "IPA Server" -> "ID Ranges" -> "Range Name"
> 
> I went through every single AD child domain and manually reconfigured both
> the "First Posix ID of the range" as well as "Number of IDs in the range" so
> we have at least 1,000,000 ID options in each child domain range:
> 
> APAC.COMPANY.ORG   1st-Posix=18   Ids-in-range: 100
> EAME.COMPANY.ORG   1st-Posix=181000   Ids-in-range: 100
> LATAM.COMPANY.ORG  1st-Posix=182000   Ids-in-range: 100
> NAFTA.COMPANY.ORG  1st-Posix=183000   Ids-in-range: 100
> 
> We are still in testing mode with less than 6 users logging in via IDM
> identities at the moment so it was not disruptive to make this sort of core
> change.

This is a valid way in testing mode. As I wrote in my other mail it is
possible and recommended in production to add additional idrange for a
domain to cover more RIDs if needed.

The difference is that the IPA server already checks if there are no
collisions in the idrange definitions and SSSD on the clients can then
just safely add the new idrange. If a definition of an idrange changes
it might be possible that existing ID-mappings changes, to be on the
safe side here SSSD requires a restart with removing the cache on all
clients.


HTH

bye,
Sumit

> 
> 
> -Chris
> 
> 
> 
> 
> 
> 
> 
> Chris Dagdigian wrote:
> > Hi folks,
> > 
> > I've posted here and gotten amazing help on our odd setup with IPA
> > having a 1-way trust to a massive remote AD forest with 90+ domain
> > controllers and lots of child domains.
> > 
> > I'm running into a strange issue where I can resolve and manage users in
> > child domain (NAFTA.COMPANY.ORG) but I am getting failures and just
> > discovered an interesting error that relates to resolving a user in the
> > EAME.COMPANY.ORG forrest.
> > 
> > However I've also been dragged down the rabbit hole tracking down errors
> > that turned out to be meaningless so I figured my 1st question will be
> > "is this the error should I be focusing on?"
> > 
> > This is my situation:
> > 
> > 1. "id u...@nafta.company.org" works perfectly fine - no issues at all
> > with RBAC, sudo and hosting SSH keys etc.
> > 
> > 2. "id u...@eame.company.org" fails with "no such user"
> > 
> > 3. We did not configure any specific SID-UID mapping rules in sssd.conf
> > as we had assumed we'd use the "default" behavior
> > 
> > 
> > After digging through the logs I found this which seems VERY clear about
> > the root cause:
> > 
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> > [dp_get_account_info_handler] (0x0200): Got request for
> > [0x1][BE_REQ_USER][1][name=u474...@eame.company.org]
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> > [sdap_idmap_sid_to_unix] (0x0040): Object SID
> > [S-1-5-21-299502267-823518204-725345543-201173] has a RID that is larger
> > than the ldap_idmap_range_size. See the "ID MAPPING” section of
> > sssd-ad(5) for an explanation of how to resolve this issue.
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> > [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID
> > [S-1-5-21-299502267-823518204-725345543-201173] to a UNIX ID
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_user]
> > (0x0020): Failed to save user [u474...@eame.company.org]
> > (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_users]
> > (0x0040): Failed to store user 0. Ignoring.
> > 
> > 
> > The error about "Object SID has a RID that is larger than
> > ldap_idmap_range_size .." seems pretty clear. I don't think this is a
> > 'rabbit hole' message - this seems like a real config problem on my end.
> > 
> > The problem is that I'm not quite sure what I should configure to
> > resolve this. The man page for sssd-ad covers the topic but does not
> > cover recommended configuration options.
> > 
> > 
> > Questions for this list:
> > 
> > 1) Confirm that the "SID has an RID that is larger ..." error is real
> > and worth chasing down ?
> > 

Re: [Freeipa-users] guidance on SID-UID mapping via sssd-ad -- one child domain works fine, 2nd domain generating SID-to-UID mapping error

[Sumit Bose]

On Wed, Feb 01, 2017 at 12:29:37PM -0500, Chris Dagdigian wrote:
> Hi folks,
> 
> I've posted here and gotten amazing help on our odd setup with IPA having a
> 1-way trust to a massive remote AD forest with 90+ domain controllers and
> lots of child domains.
> 
> I'm running into a strange issue where I can resolve and manage users in
> child domain (NAFTA.COMPANY.ORG) but I am getting failures and just
> discovered an interesting error that relates to resolving a user in the
> EAME.COMPANY.ORG forrest.
> 
> However I've also been dragged down the rabbit hole tracking down errors
> that turned out to be meaningless so I figured my 1st question will be "is
> this the error should I be focusing on?"
> 
> This is my situation:
> 
> 1. "id u...@nafta.company.org" works perfectly fine - no issues at all with
> RBAC, sudo and hosting SSH keys etc.
> 
> 2. "id u...@eame.company.org" fails with "no such user"
> 
> 3. We did not configure any specific SID-UID mapping rules in sssd.conf as
> we had assumed we'd use the "default" behavior
> 
> 
> After digging through the logs I found this which seems VERY clear about the
> root cause:
> 
> (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> [dp_get_account_info_handler] (0x0200): Got request for
> [0x1][BE_REQ_USER][1][name=u474...@eame.company.org]
> (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> [sdap_idmap_sid_to_unix] (0x0040): Object SID
> [S-1-5-21-299502267-823518204-725345543-201173] has a RID that is larger
> than the ldap_idmap_range_size. See the "ID MAPPING” section of sssd-ad(5)
> for an explanation of how to resolve this issue.
> (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]]
> [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID
> [S-1-5-21-299502267-823518204-725345543-201173] to a UNIX ID
> (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_user]
> (0x0020): Failed to save user [u474...@eame.company.org]
> (Wed Feb 1 17:02:18 2017) [sssd[be[companyidm.org]]] [sdap_save_users]
> (0x0040): Failed to store user 0. Ignoring.
> 
> 
> The error about "Object SID has a RID that is larger than
> ldap_idmap_range_size .." seems pretty clear. I don't think this is a
> 'rabbit hole' message - this seems like a real config problem on my end.

Yes, unfortunately this messages is a bit misleading on an IPA client
because here you do not have to fix the local configuration but you only
have to add an id-range on an IPA server. Please check the existing
id-ranges with

ipa idrange-find

There should be already one for EAME.COMPANY.ORG with the default size
of 20 ("Number of IDs in the range: 20"). Please add a second
idrange for EAME.COMPANY.ORG which covers the RIDs above 20. If you
need help with choosing the parameters please send the idrange-find
output.

HTH

bye,
Sumit

> 
> The problem is that I'm not quite sure what I should configure to resolve
> this. The man page for sssd-ad covers the topic but does not cover
> recommended configuration options.
> 
> 
> Questions for this list:
> 
> 1) Confirm that the "SID has an RID that is larger ..." error is real and
> worth chasing down ?
> 
> 2) My understanding was that by default SSSD will hash SIDs and come up with
> unique UID and GID ranges that will be consistent across any machine bound
> to the same IDM mechanism. So I've not configured anything specific related
> to SID-to-UID mapping as we wanted to go with the default behavior used by
> SSSD. Obviously the default is not working and I've got to make a change. I
> just don't know what the recommended change should be. Help appreciated!
> 
> 
> 
> Config file details are below.
> 
> 
> Regards,
> Chris
> 
> 
> 
> 
> 
> This is the sssd/sssd.conf file on the IPA server:
> 
> ###--
> 
> [domain/companyidm.org]
> ldap_user_principal = nosuchattr
> subdomain_inherit = ldap_user_principal
> debug_level = 5
> krb5_validate = True
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = companyidm.org
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = usaeilidmp001.companyidm.org
> chpass_provider = ipa
> ipa_server = usaeilidmp001.companyidm.org
> ipa_server_mode = True
> ldap_tls_cacert = /etc/ipa/ca.crt
> [sssd]
> services = nss, sudo, pam, ssh
> config_file_version = 2
> 
> domains = companyidm.org
> [nss]
> memcache_timeout = 600
> homedir_substring = /home
> 
> [pam]
> debug_level = 5
> [sudo]
> 
> [autofs]
> 
> [ssh]
> debug_level = 5
> 
> [pac]
> 
> [ifp]
> 
> ###--
> 
> 
> This is krb5.conf which handles the child domain and trust things ...
> 
> [capaths]
> COMPANYAWS.ORG = {
> COMPANYIDM.ORG = COMPANYAWS.ORG
> }
> COMPANYIDM.ORG = {
> COMPANYAWS.ORG = COMPANYAWS.ORG
> SYNGENTA.ORG = COMPANY.ORG
> EAME.COMPANY.ORG = SYNGENTA.ORG
> APAC.COMPANY.ORG = SYNGENTA.ORG
> LATAM.COMPANY.ORG = SYNGENTA.ORG
> NAFTA.COMPANY.ORG = SYNGENTA.ORG
> }
> COMPANY.ORG = {
> COMPANYIDM.ORG = COMPANY.ORG
> }
> 

Re: [Freeipa-users] performance scaling of sssd / freeipa

[Sumit Bose]

On Wed, Jan 25, 2017 at 10:58:34PM +, Sullivan, Daniel [CRI] wrote:
> Hi,
> 
> My apologizes for resurrecting this thread.  This issue is still ongoing, at 
> this point we’ve been looking at it for over a week and now have more than 
> one staff member analyzing and trying to resolve it on a full time basis.  I 
> have some more information that I was hoping an a seasoned IPA expert could 
> take a look at.   At this point I am fairly certain it is a performance 
> tuning issue in either sssd or FreeIPA on the our domain controllers.  It 
> looks to me like the main issue is that when looking up the same user across 
> a large number of nodes in parallel, all of our available ds389 threads get 
> blocked with '__lll_robust_lock_wait ()’ for operations involving 
> ipa_extdom_common.c.  This usually occurs on one of our two DCs, but 
> occasionally on both.   For example, in the attached output, out of 199 
> threads in the attached output, 179 are in the status __lll_robust_lock_wait 
> ().  All of the us...@xxx.uchicago.edu in 
> this attachment are the same user.
> 
> Here is more information about this issue (some of it repeated for 
> convenience):
> 
>   1.  We currently have 2 domain controllers.  Each has 6 processor cores and 
> 180 threads allocated for 389ds.  We have gone through Red Hat’s performance 
> tuning guide for directory services made what we felt were appropriate 
> changes, and made additional tuning modifications to get lowered eviction 
> rates and high cache hit numbers for 389ds.  We have approximately 220 
> connections to our domain controllers (from "cn=monitor”), depending on the 
> test I’ve seen as many as 190 connected to a single DC.
>   2.  We are using an AD domain where all of our users and groups reside.
>   3.   I induce this by looking up a user (using the id command) on a large 
> number of nodes (maybe 200) for a user that has never been looked up before, 
> and is not cached on either the client, or on the DC.
>   4.   Before I induce the problem, I can lookup entries in LDAP without 
> delay or problem (i.e. the LDAP server is performant and responsive, I can 
> inspect cn=monitor or cn=config and get instantaneous results).
>   5.  When I do induce the issue, the LDAP server basically becomes 
> unresponsive (which is expected based on the attached output).  Servicing a 
> query using the ldapsearchtool (for either cn=monitor or cn=config) can take 
> upwards of 1-2 minutes or longer.  Eventually the LDAP server will ‘recover’, 
> i.e. I do not typically need to restart IPA services to get this working 
> again.
>   6.  After a lookup fails, subsequent parallel lookups succeed and return 
> the desired record (presumably from the cache).
>   7.  It appears that these failures are also characterized by a 
> corresponding "[monitor_hup] (0x0020): Received SIGHUP.”  in the sssd log.
>   8.  Right before the problem occurs I see a brief spike in CPU utilization 
> of the ns-slapd process, then the utilization basically drops to 0 once the 
> threads are blocked in ns-slapd.
>   9.  Since we are doing computation in our IPA environment, it is important 
> that we can perform these types of parallel operations against our IPA 
> environment at the scale we are testing.
> 
> I feel like we are either DoSing the LDAP server or the sss_be / sss_nss 
> processes, although I am not sure.   Right now we are in the process of 
> deploying an additional domain controller to see if that helps with 
> distribution of load.  If anybody could provide any sort of information with 
> respect addressing the issue in the attached trace I would be very grateful.

I think your observations are due to the fact that SSSD currently
serializes connections from a single process. Your clients will call the
extdom extended LDAP operation on the IPA server to get the information
about the user from the trusted domain. The extdom plugin runs inside of
389ds and each client connection will run in a different thread. To get
the information about the user from the trusted domain the extdom plugin
calls SSSD and here is where the serialization will happen, i.e. all
threads have to wait until the first one will get his results and the
next thread can talk to SSSD.

With an empty cache the initial lookup of a user and all its groups will
take some time and since you used quite a number of clients all 389ds
worker threads will be "busy" waiting to talk to SSSD so that it would
even be hard for other request, even the ones which do not need to talk
to SSSD, to get through because there are no free worker threads.

To improve the situation maybe setting 'ignore_group_members=True' as
described on
https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-large-ipa-ad-trust-deployments/
which you already mentioned might help.

Although in general not recommend depending on the size of the trusted
domain (i.e. the number of users and groups in the 

Re: [Freeipa-users] performance scaling of sssd / freeipa

[Sumit Bose]

On Fri, Jan 20, 2017 at 03:41:46PM +, Sullivan, Daniel [CRI] wrote:
> Hi,
> 
> I have some more information on this issue.  I’m tracing it down through the 
> slapd logs and  I am continuing to struggle; I was hoping that somebody could 
> possibly help me provided this additional information.
> 
> On the domain logs (on the DC), I see an ldap_search_ext operation 155 with a 
> timeout of 60:
> 
> (Fri Jan 20 08:42:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with 
> [(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-xxx))][cn=Default
>  Trust View,cn=views,cn=accounts,dc=xxx,dc=xxx,dc=uchicago,dc=edu].
> (Fri Jan 20 08:42:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 155
> (Fri Jan 20 08:42:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] [sdap_op_add] 
> (0x2000): New operation 155 timeout 60
> 
> Then, on the slapd log for the server, I see the incoming request.  Based on 
> the result, it looks like the request completes successfully within 1 second:
> 
> [20/Jan/2017:08:42:35.179890746 -0600] conn=1518 op=31 SRCH base="cn=Default 
> Trust View,cn=views,cn=accounts,dc=xxx,dc=xxx,dc=uchicago,dc=edu" scope=2 
> filter="(&(objectClass=ipaOverrideAnchor)(ipaAnchorUUID=:SID:S-1-5-21-xxx))" 
> attrs=ALL
> [20/Jan/2017:08:42:35.683485674 -0600] conn=1518 op=31 RESULT err=0 tag=101 
> nentries=0 etime=1 notes=U
> 
> Then, subsequently, the domain log (on the DC), I see the same operation 155 
> timeout (expectedly almost a minute later).

So it looks like ns-ldap send the response but it never reached SSSD in
time. Can you send what it happening in the SSSD logs between 08:42:34
and 08:43:34 (if you prefer you can send it to me directly). Maybe there
is an operation which blocks SSSD for too long so that it returns too
late to the main loop to process the response?

bye,
Sumit

> 
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] [sdap_op_timeout] 
> (0x1000): Issuing timeout for 155
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [sdap_op_destructor] (0x1000): Abandoning operation 155
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [generic_ext_search_handler] (0x0040): sdap_get_generic_ext_recv failed 
> [110]: Connection timed out
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [ipa_get_ad_override_done] (0x0040): ipa_get_ad_override request failed.
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [sdap_id_op_destroy] (0x4000): releasing operation connection
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [ipa_initgr_get_overrides_override_done] (0x0040): IPA override lookup 
> failed: 110
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [ipa_id_get_groups_overrides_done] (0x0040): IPA resolve user groups 
> overrides failed [110].
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [be_mark_dom_offline] (0x1000): Marking subdomain bsdad.uchicago.edu offline
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [be_mark_subdom_offline] (0x1000): Marking subdomain bsdad.uchicago.edu as 
> inactive
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [ipa_srv_ad_acct_lookup_done] (0x0040): ipa_get_*_acct request failed: [110]: 
> Connection timed out.
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [ipa_subdomain_account_done] (0x0040): ipa_get_*_acct request failed: [110]: 
> Connection timed out.
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [sdap_id_op_destroy] (0x4000): releasing operation connection
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [dp_reply_std_set] (0x0080): DP Error is OK on failed request?
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] [dp_req_done] 
> (0x0400): DP Request [Account #4292]: Request handler finished [0]: Success
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] [_dp_req_recv] 
> (0x0400): DP Request [Account #4292]: Receiving request data.
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [dp_req_reply_list_success] (0x0400): DP Request [Account #4292]: Finished. 
> Success.
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [dp_req_reply_std] (0x1000): DP Request [Account #4292]: Returning [Success]: 
> 0,110,Success
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [dp_table_value_destructor] (0x0400): Removing 
> [0:1:0x0001:1:1::bsdad.uchicago.edu:name=user...@domain.uchicago.edu] from 
> reply table
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [dp_req_destructor] (0x0400): DP Request [Account #4292]: Request removed.
> (Fri Jan 20 08:43:34 2017) [sssd[be[xxx.xxx.uchicago.edu]]] 
> [dp_req_destructor] (0x0400): Number of active DP request: 1
> 
> It seems like whatever problem I have is a communication issue between sssd 
> on the domain 

Re: [Freeipa-users] IPA Client will authenticate users

[Sumit Bose]

On Thu, Jan 19, 2017 at 04:33:59PM -0600, Michael Rainey (Contractor) wrote:
> Hello everyone,
> 
> I have come across a problem which you might find interesting. With all of
> the systems I have running, there is one system which refuses to
> authenticate any user who needs to login.  I have deleted and reinstalled
> the to the domain in the hopes it would resolve the problem.  I have copied
> pam files from working systems to the failing system to see if this action
> would fix the problem.  No such luck.
> 
> I've included the sssd_pam.log file starters.

Looks like authentication is ok but access control denies access. You
should check the domain log for reasons why access is denied.

HTH

bye,
Sumit

> 
> Thanks in advance.
> -- 

-- 
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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]

[Sumit Bose]

On Tue, Jan 17, 2017 at 04:12:51PM +0100, Harald Dunkel wrote:
> On 01/17/17 11:38, Sumit Bose wrote:
> > On Tue, Jan 17, 2017 at 10:44:14AM +0100, Harald Dunkel wrote:
> >> It seems something got corrupted in my ipa setup. I found this in the
> >> sssd log file on Wheezy:
> >>
> >> (Tue Jan 17 10:19:02 2017) [hbac_shost_attrs_to_rule] (0x0400): Processing 
> >> source hosts for rule [allow_all]
> >> (Tue Jan 17 10:19:02 2017) [hbac_eval_user_element] (0x0080): Parse error 
> >> on [cn=System: Manage Host 
> >> Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de]
> > 
> > Looks like there was a replication conflict, please see
> > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
> > how to resolve it.
> > 
> 
> % ldapsearch -D "cn=directory manager" -w secret -b "dc=example,dc=de" 
> "nsds5ReplConflict=*" \* nsds5ReplConflict | grep nsds5ReplConflict | wc -l
> 26
> 
> :-(
> 
> I have 4 ipa servers. How can I make sure that no new problem arises
> while I try to cleanup this mess? Can I freeze Freeipa somehow to
> resolve this?
> 
> > We already have a ticket for SSSD to ignore those object, but
> > unfortunately there is currently no patch available for SSSD so you have
> > to resolve the replication conflict to get it working again.
> > 
> 
> You mean sssd should ignore the conflict, not telling anybody?
> I am not sure if thats the right way.

SSSD will of course write a log messages when a DN is ignored. Since the
default for HBAC is deny and a rule must allow you access e.g. a missing
group membership will in the worst case cause a denied access because
not all criteria defined be the rule are matched.

bye,
Sumit

> 
> 
> Thanx very much for your advice
> Harri
> 
> -- 
> 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] be_pam_handler_callback Backend returned: (3, 4, ) [Internal Error (System error)]

[Sumit Bose]

On Tue, Jan 17, 2017 at 10:44:14AM +0100, Harald Dunkel wrote:
> It seems something got corrupted in my ipa setup. I found this in the
> sssd log file on Wheezy:
> 
> (Tue Jan 17 10:19:02 2017) [hbac_shost_attrs_to_rule] (0x0400): Processing 
> source hosts for rule [allow_all]
> (Tue Jan 17 10:19:02 2017) [hbac_eval_user_element] (0x0080): Parse error on 
> [cn=System: Manage Host 
> Principals+nsuniqueid=109be36e-ccd911e6-a5b3d0c8-d8da17db,cn=permissions,cn=pbac,dc=example,dc=de]

Looks like there was a replication conflict, please see
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
how to resolve it.

We already have a ticket for SSSD to ignore those object, but
unfortunately there is currently no patch available for SSSD so you have
to resolve the replication conflict to get it working again.

HTH

bye,
Sumit

> (Tue Jan 17 10:19:02 2017) [hbac_ctx_to_rules] (0x0020): Could not construct 
> eval request
> (Tue Jan 17 10:19:02 2017) [ipa_hbac_evaluate_rules] (0x0020): Could not 
> construct HBAC rules
> (Tue Jan 17 10:19:02 2017) [be_pam_handler_callback] (0x0100): Backend 
> returned: (3, 4, ) [Internal Error (System error)]
> (Tue Jan 17 10:19:02 2017) [be_pam_handler_callback] (0x0100): Sending result 
> [4][example.de]
> (Tue Jan 17 10:19:02 2017) [be_pam_handler_callback] (0x0100): Sent result 
> [4][example.de]
> 
> This happens on a login via ssh, or if I run "su - username" as
> root. The su session gives just a warning, but for sshd I have to
> disable pam to allow remote logins.
> 
> Complete log is attached, of course.
> 
> 
> Every helpful comment is highly appreciated.
> Harri

-- 
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 as Samba Backend, Existing Users Fail

[Sumit Bose]

On Wed, Jan 11, 2017 at 04:00:57PM -0500, Armaan Esfahani wrote:
> Hi, I have setup a Samba server to use FreeIPA as a password backend, however 
> whenever I try to use existing users to login I get 
> “NT_STATUS_LOGON_FAILURE”. 
> 
> Looking at the sssd_nss log on my ipa server, I get the following error “(Wed 
> Jan 11 15:56:11 2017) [sssd[nss]] [fill_sid] (0x0020): Missing SID.”  On all 
> existing accounts, whereas all new accounts function properly (after 
> resetting their passwords).
> 
>  
> 
> Anyone have any ideas?

Maybe the sidgen task was run during ipa-adtrust-install, please see
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/creating-trusts.html#create-trust-existing-idm
how to run it.

HTH

bye,
Sumit

> 

> -- 
> 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] Not able to replicate user keys across master and client

[Sumit Bose]

On Thu, Jan 12, 2017 at 10:59:04AM +, hirofumi.morik...@accenture.com wrote:
> Hi Free IPA team
> 
> Let me further clarify the question that is asked by Niraj below.
> 
> Currently, we have 1 master FreeIPA server and 1 client server. Evaluating 
> your product for production deployment
> Master and client connectivity is established and when creating the user in 
> the web console, it is indeed creating the user in the client machine
> 
> However, When we add public key through the web console below, this key is 
> not created(or transfered) to the client machine(checked by logging into the
> server) that blocks the key based access to this machine
> 
> [cid:image003.jpg@01D26CCB.55E68FA0]

Does the web console show the key's fingerprint after you added it as
shown in
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/user-keys.html


> 
> 
> Could you please let us know if this key is supposed to be created to the 
> client machine natively with FreeIPA
> when registering the key through the console above?  Are we missing any 
> configuration to enable this
> key registration to client machine? Thank you for your response in advance

If you used ipa-join or realmd to join the IPA client to the IPA server
everything should be configured correctly.

In /etc/ssh/sshd_config you should find the line 'AuthorizedKeysCommand
/usr/bin/sss_ssh_authorizedkeys' which tells sshd to call
sss_ssh_authorizedkeys to get the key.

You can call 'sss_ssh_authorizedkeys' directly with the user name as
argument to see if the key is returned:

# sss_ssh_authorizedkeys testuser
ssh-rsa B3Nz...

If nothing is returned you should check /var/log/sssd/sssd_ssh.log for
errors. You might need to increase in debug_level in the [ssh] section
of sssd.conf first, see
https://fedorahosted.org/sssd/wiki/Troubleshooting for details.

HTH

bye,
Sumit

> 
> Best regards
> 
> Hirofumi Morikawa
> Accenture
> Certified Technology Architect - Emerging Technologies group
> Email : 
> hirofumi.morik...@accenture.com
> Mobile phone : +33 (0)6 82 10 81 88
> 
> From: Singh, NirajKumar
> Sent: mardi 10 janvier 2017 10:38
> To: freeipa-users@redhat.com
> Cc: Morikawa, Hirofumi; Shyam Gupta, Upendra
> Subject: Not able to replicate user keys across master and client
> 
> Hi Team,
> 
> We have Created PPK key for the user on master FreeIPA server  which is there 
> in /home/user/.ssh/authorized_keys file.
> 
> But the key are not reflecting in client machine.
> 
> Please suggest so that authorized_keys file added automatically in client as 
> soon as it gets created in master server.
> 
> Thanks,
> Niraj
> 
> 
> 
> This message is for the designated recipient only and may contain privileged, 
> proprietary, or otherwise confidential information. If you have received it 
> in error, please notify the sender immediately and delete the original. Any 
> other use of the e-mail by you is prohibited. Where allowed by local law, 
> electronic communications with Accenture and its affiliates, including e-mail 
> and instant messaging (including content), may be scanned by our systems for 
> the purposes of information security and assessment of internal compliance 
> with Accenture policy.
> __
> 
> www.accenture.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] Different cache on 2 IPA servers

[Sumit Bose]

On Wed, Jan 11, 2017 at 11:01:22AM +0100, Troels Hansen wrote:
> Hi, we have just seen a weird issue, which I need some advice on. 
> 
> We have 2 IPA 4.4 servere in a AD trust and a number of Linux clients 
> connected. 
> 
> A little story of what we experienced. 
> We had a AD user which sometimes couldn't log in to a server, because his 
> shell was being set to /bin/false by SSSD. 
> 
> "sss_cache -E", deleting local cache in /var/lib/sssd/mc and db and 
> restarting SSSD sometimes led to the users having a correct shell set, but 
> still, after some hours most likely having his shell being set back to 
> /bin/false. 
> 
> We discovered that when the clients was connected to one IPA server the shell 
> was set to /bin/false and when connected to the other, the shell from SSSD, 
> default_shell was set. 
> 
> This led us to investigate the SSSD cache (in /var/lib/sssd/db/) on the IPA 
> serveres, and there we discovered that on one server a loginShell was set 
> whilst it wasn't on the other. 
> 
> ldapsearch the user on the AD servers had the loginShell: /bin/false 
> 
> However, one IPA server still had an idea that loginShell wasn't set. 
> 
> sss_cache -E on the IPA server correcthe the issue. 
> 
> This attribute have been on the user for ages, so do anyone have any idea of 
> how this can happen? 
> 
> sssd config and everything about the serveres are the same. Also, SSSD cache 
> config.ldb contained the same values on both servers. 
> 
> 
> Second question. The reason for the loginshell being set on some users is 
> that they used to be 
> Hi, we have just seen a weird issue, which I need some advice on. 
> 
> We have 2 IPA 4.4 servere in a AD trust and a number of Linux clients 
> connected. 
> 
> A little story of what we experienced. 
> We had a AD user which sometimes couldn't log in to a server, because his 
> shell was being set to /bin/false by SSSD. 
> 
> "sss_cache -E", deleting local cache in /var/lib/sssd/mc and db and 
> restarting SSSD sometimes led to the users having a correct shell set, but 
> still, after some hours most likely having his shell being set back to 
> /bin/false. 
> 
> We discovered that when the clients was connected to one IPA server the shell 
> was set to /bin/false and when connected to the other, the shell from SSSD, 
> default_shell was set. 
> 
> This led us to investigate the SSSD cache (in /var/lib/sssd/db/) on the IPA 
> serveres, and there we discovered that on one server a loginShell was set 
> whilst it wasn't on the other. 
> 
> ldapsearch the user on the AD servers had the loginShell: /bin/false 
> 
> However, one IPA server still had an idea that loginShell wasn't set. 
> 
> sss_cache -E on the IPA server correcthe the issue. 
> 
> This attribute have been on the user for ages, so do anyone have any idea of 
> how this can happen? 

I guess this is because the last update on one server was done with data
from LDAP while the other used data from the Global Catalog. In general
missing data in the GC should not remove the data read from LDAP, there
is already https://fedorahosted.org/sssd/ticket/2474 to track this.

> 
> So, the actual error was that the user was actually allowed to log in but as 
> we discovered the actual reason, the question is, why the cache isn't updated 
> and contains different content on the IPA servers. 
> 
> sssd config and everything about the serveres are the same. Also, SSSD cache 
> config.ldb contained the same values on both servers. 
> 
> 
> Second question. The reason for the loginshell being set on some users is 
> that they used to be QAU, which enabled the UNIX attributes on the user, and 
> disabling the user in QAS sets the shell to /bin/false. 
> So, what we would really like is to override if a user have a shell in AD, by 
> setting "ldap_user_shell = something-false" on the IPA servers, but this 
> isn't inherited to sub-domains? 
> 
> Can disabling shell's be accomplished somehow else? 

We plan to allow to configure sub-domains individually in one of the
next releases, see https://fedorahosted.org/sssd/ticket/2599 .

In the meantime you might want to try id-overrides for users which have
/bin/false set as shell in AD?

HTH

bye,
Sumit

> 
> 

> -- 
> 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] 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] 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] 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] Failed to connect, going offline (5 [Input/output error])

[Sumit Bose]

On Fri, Jan 06, 2017 at 11:31:31AM +0100, rajat gupta wrote:
> Hi,
> 
> only few user are able to login. ipa ad-trust setup.

more details are needed here. Can you at least share sssd.conf from the
ilt-gif-ipa02?

> 
> ==
> 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
> 146.213.128.135
> 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'

Is it expected that ilt-gif-ipa01.ipa.preprod.local is not reachable?
Does authentication work on this server? Please send the full log so that it
can be checked what happened before and why SSSD assumes that the server
is 'not working'.

bye,
Sumit

> (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
> 
> 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
> 
> 
> 
> -- 
> 
> *Rajat Gupta*

> -- 
> 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] Debian: libpam-sss pam-configs update?

[Sumit Bose]

On Wed, Jan 04, 2017 at 10:39:37AM +0100, Jochen Hein wrote:
> 
> Hi,
> 
> I'm still working on my Debian systems to get local login to work with
> OTP.
> 
> In /etc/pam.d/common-auth we have:
> auth[success=2 default=ignore]  pam_unix.so nullok_secure
> auth[success=1 default=ignore]  pam_sss.so use_first_pass
> 
> On CentOS we have something more complicated in /etc/pam.d/system-auth:
> 
> auth[default=1 success=ok] pam_localuser.so
> auth[success=done ignore=ignore default=die] pam_unix.so nullok 
> try_first_pass
> authrequisite pam_succeed_if.so uid >= 1000 quiet_success
> authsufficientpam_sss.so forward_pass
> 
> I think we need something more elaborated for debian to replicate the
> (good!) experience from CentOS when asking for "First/Second Factor".
> The four lines from above work well, but how can we get that into
> pam-auth-update? Any ideas how this could be packaged?

The 

auth[default=1 success=ok] pam_localuser.so

line was added in CentOS/RHEL to make sure that the PAM conversation is
run by pam_sss for users managed by SSSD and not by pam_unix because
pam_unix can only ask for a password. It would have been possible to
call pam_sss first but it was considered safer to have pam_unix first to
make sure root login will always handled by pam_unix.

It has to be noted that pam_sss currently is a bit special when a
modules called earlier, e.g. pam_unix, put a password on the PAM stack.
Only if use_first_pass is used pam_sss will use the password on the
stack but also will never prompt on its own. If use_first_pass is not
used pam_sss will always prompt on its own and never check if there is
already a password in the stack. This behaviour was there since the very
first versions of pam_sss because we didn't wanted to copy the
try_first_pass behaviour of other PAM modules because this try-and-error
scheme might easily wrong password counters and lock accounts. So we
assumed that pam_sss is either the first module or will get the password
from other modules. This is why there is the 'default=die' option in the
pam_unix line for CentOS. But it turns out that there are valid use
cases where pam_sss should handle the prompting for SSSD users but
should accept a password on the PAM stack as well.

We plan to fix this with https://fedorahosted.org/sssd/ticket/2984 so
that pam_sss will check for a password on the PAM stack even if
use_first_pass is not set. But if there is one pam_sss will only use
this and will not prompt for other credentials is password
authentication fails. So the pam_localuser line will still be needed to
make sure users handled by SSSD will be prompted by pam_sss exclusively.

HTH

bye,
Sumit

> 
> Jochen
> 
> -- 
> The only problem with troubleshooting is that the trouble shoots back.
> 
> -- 
> 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] Unspecified GSS failure. Minor code may provide more information KDC has no support for encryption type

[Sumit Bose]

On Mon, Jan 02, 2017 at 11:03:36PM +0530, tarak sinha wrote:
> Hi Team,
> 
> I am getting below error while trying to ssh my host without password.
> 
> Unspecified GSS failure. Minor code may provide more information KDC has no
> support for encryption type

Where do you see this error, on the client where you call ssh or in the
logs on the host you try to log in to? Are you using IPA user or do you
use trust and AD users from a trusted domain?

Do you see any related messages in the KDC logs?

bye,
Sumit

> 
> Thanks in advance
> 
> *Thanks,*
> 
> *Tarak Nath Sinha*

> -- 
> 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 and 2fa with mac OS X client

[Sumit Bose]

On Thu, Dec 15, 2016 at 06:50:53PM +, Mark Steele wrote:
> Still no luck.
> 
> 
> klist
> Credentials cache: API:4FE16A36-A5AB-476F-8B49-4B427E816279
> Principal: ad...@int.domain.com
> 
>   IssuedExpires   Principal
> Dec 15 13:45:09 2016  Dec 16 13:45:07 2016  
> krbtgt/int.domain@int.domain.com
> 
> 
> KRB5_TRACE=/dev/stdout kinit 
> --fast-armor-cache=API:4FE16A36-A5AB-476F-8B49-4B427E816279 
> mark.ste...@int.domain.com
> 2016-12-15T13:35:35 set-error: -1765328242: Reached end of credential caches
> 2016-12-15T13:35:35 set-error: -1765328243: Principal 
> mark.ste...@int.domain.com not found in any credential cache
> mark.ste...@int.domain.com's password: 
> 2016-12-15T13:35:50 set-error: -1765328234: Encryption type 
> des-cbc-md5-deprecated not supported
> 2016-12-15T13:35:50 Adding PA mech: SRP
> 2016-12-15T13:35:50 Adding PA mech: ENCRYPTED_CHALLENGE
> 2016-12-15T13:35:50 Adding PA mech: ENCRYPTED_TIMESTAMP
> 2016-12-15T13:35:50 krb5_get_init_creds: loop 1
> 2016-12-15T13:35:50 KDC sent 0 patypes
> 2016-12-15T13:35:50 Trying to find service kdc for realm INT.DOMAIN.COM flags > 0
> 2016-12-15T13:35:50 configuration file for realm INT.DOMAIN.COM found
> 2016-12-15T13:35:50 submissing new requests to new host
> 2016-12-15T13:35:50 connecting to host: udp 10.44.4.50:kerberos 
> (ds01.int.domain.com) tid: 0001
> 2016-12-15T13:35:50 writing packet: udp 10.44.4.50:kerberos 
> (ds01.int.domain.com) tid: 0001
> 2016-12-15T13:35:51 Configuration exists for realm INT.DOMAIN.COM, wont go to 
> DNS
> 2016-12-15T13:35:51 out of hosts, waiting for replies
> 2016-12-15T13:36:01 retrying sending to: udp 10.44.4.50:kerberos 
> (ds01.int.domain.com) tid: 0001
> 2016-12-15T13:36:01 writing packet: udp 10.44.4.50:kerberos 
> (ds01.int.domain.com) tid: 0001
> 2016-12-15T13:36:12 retrying sending to: udp 10.44.4.50:kerberos 
> (ds01.int.domain.com) tid: 0001
> 2016-12-15T13:36:12 writing packet: udp 10.44.4.50:kerberos 
> (ds01.int.domain.com) tid: 0001
> 2016-12-15T13:36:23 host timed out: udp 10.44.4.50:kerberos 
> (ds01.int.domain.com) tid: 0001

Your client does not fall back to TCP. It is at least recommended to use
TCP with OTP (see https://fedorahosted.org/freeipa/ticket/4725). Iirc
with heimdal you can use

   kdc = tcp/ds01.int.domain.com:88

to force the client using TCP.

HTH

bye,
Sumit
  
> 2016-12-15T13:36:23 no more hosts to send/recv packets to/from trying to 
> pulling more hosts
> 2016-12-15T13:36:23 set-error: -1765328228: unable to reach any KDC in realm 
> INT.DOMAIN.COM, tried 1 KDC
> 2016-12-15T13:36:23 krb5_sendto_context INT.DOMAIN.COM done: -1765328228 
> hosts 1 packets 3 wc: 33.115489 nr: 0.000804 kh: 0.000915 tid: 0001
> kinit: krb5_get_init_creds: unable to reach any KDC in realm INT.DOMAIN.COM, 
> tried 1 KDC
> 
> 
> mac client config (OS 10.11.1):
> 
> cat /etc/krb5.conf 
> [libdefaults]
> default_realm = INT.DOMAIN.COM
> dns_lookup_realm = true
> dns_lookup_kdc = true
> ticket_lifetime = 24h
> forwardable = yes
> renewable = true
> 
> 
> [realms]
>  INT.DOMAIN.COM = {
>   kdc = ds01.int.domain.com:88
>   master_kdc = ds01.int.domain.com:88
>   admin_server = ds01.int.domain.com:749
>   default_domain = int.domain.com
>   pkinit_anchors = FILE:/etc/ipa/ca.crt
> }
> 
> [domain_realm]
>  .int.domain.com = INT.DOMAIN.COM
>  int.domain.com = INT.DOMAIN.COM
> 
> On the freeipa server’s krb5kdc.log:
> 
> krb5kdc: Realm not local to KDC - while dispatching (udp)
> 
> When authenticating with a non 2FA user, works fine.
> 
> Anyone can hit me with a clue-stick?
> 
> Cheers,
> 
> Mark
> 
> 
> 
> On 2016-12-15, 11:20 AM, "freeipa-users-boun...@redhat.com on behalf of 
> Alexander Bokovoy" <freeipa-users-boun...@redhat.com on behalf of 
> aboko...@redhat.com> wrote:
> 
> On to, 15 joulu 2016, Sumit Bose wrote:
> >On Thu, Dec 15, 2016 at 03:38:14PM +, Mark Steele wrote:
> >> Hi,
> >>
> >> Has anyone managed to make this work and if so, is there some 
> documentation for doing so?
> >>
> >> I can successfully authenticate to my linux servers using 2FA, but am
> >> unable to get my Mac to be able to get a ticket with kinit.
> >>
> >> Kinit returns: “password incorrect”, and isn’t prompting for the
> >> second factor. I’ve also tried appending the second factor to the
> >> password (like when logging into the UI).
> >>
> >> Any help would be appreciated.
> >
> >For 2FA FAST is needed http://www.fr

Re: [Freeipa-users] Kerberos and 2fa with mac OS X client

[Sumit Bose]

On Thu, Dec 15, 2016 at 03:38:14PM +, Mark Steele wrote:
> Hi,
> 
> Has anyone managed to make this work and if so, is there some documentation 
> for doing so?
> 
> I can successfully authenticate to my linux servers using 2FA, but am unable 
> to get my Mac to be able to get a ticket with kinit.
> 
> Kinit returns: “password incorrect”, and isn’t prompting for the second 
> factor. I’ve also tried appending the second factor to the password (like 
> when logging into the UI).
> 
> Any help would be appreciated.

For 2FA FAST is needed http://www.freeipa.org/page/V4/OTP#kinit_Method.
For MacOS I found
https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man1/kinit.1.html
and according to this the MacOS kinit does not support FAST, i.e. using
an armor credential cache. But maybe there are newer or alternative
versions which supports it?

HTH

bye,
Sumit
> 
> 
> Thanks
> 
> Mark
> 
> 

> -- 
> 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] Free IPA Openssh client install error

[Sumit Bose]

On Wed, Dec 14, 2016 at 03:18:52PM +, James Harrison wrote:
> Hi,I installed the freeipa client on an Ubuntu Precise system (12.04)
> 
> I get the following message at the end of the install:
> "Installed OpenSSH server does not support dynamically loading authorized 
> user keys. Public key authentication of IPA users will not be available."
> 
> Any clues? Is there a fix?

Either OpenSSH on Ubuntu 12.04 does not support the
AuthorizedKeysCommand sshd option or the checks ipa-client-install is
trying do not match.

ipa-client-install calls

sshd -t -f /dev/null -o 
AuthorizedKeysCommand=/usr/bin/sss_ssh_authorizedkeys -o 
AuthorizedKeysCommandUser=nobody

to check if sshd supports the option. It also tries
'AuthorizedKeysCommand' with 'AuthorizedKeysCommandRunAs' and
'PubKeyAgent' with 'PubKeyAgentRunAs'.

Do you see related messages in /var/log/ipaclient-install.log ?

HTH

bye,
Sumit

> 
> Best regards,James Harrison

> -- 
> 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] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts

[Sumit Bose]

On Thu, Dec 08, 2016 at 11:37:25AM -0500, Chris Dagdigian wrote:
> 
> Massive thank you; will test ASAP.
> 
> We mainly have to support CentOS/RHEL-6 and CentOS/RHEL-7 clients. Is there
> any established guidance on upgrading SSSD in these environments? Some sort
> of trusted repo where RPMs are built? I can hit the wiki and website but
> figured I'd ask as well. Not sure what other dependencies the SSSD framework
> may have or pull in.

You might want to have a look at
https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-14/ . Lukas is
doing a great job here in providing test-builds of the latest versions
release in Fedora for other/older platforms.

But please note those are test-build. You have to wait until CentOS
release the 7.3 packages to have an 'official' sssd-1.14 build.

HTH

bye,
Sumit
> 
> Sumit Bose wrote:
> > }
> > 
> > at the very beginning of /etc/krb5.conf before and include or includedir
> > directives should fix it. With the broken configuration libkrb5 thinks
> > that there direct trust between NAFTA.COMPANY.ORG and COMPANYIDM.ORG
> > which is not the case, everything has to go via COMPANY.ORG because
> > that's the domain which trusts COMPANYIDM.ORG.
> > 
> > Updating SSSD to a version with the fix might help as well.
> > 
> > HTH
> 

-- 
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] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts

[Sumit Bose]

On Thu, Dec 08, 2016 at 09:29:34AM -0500, Chris Dagdigian wrote:
> 
> Sumit Bose wrote:
> > > >  Am I being stupid (again?)  Obviously the krb5_validate=false setting 
> > > > needs
> > > >  to be fixed. Just not sure if I should work on a fix within 4.2 or 
> > > > move to
> > > >  4.4 and see if it gets resolved as part of other changes.
> > 
> > The validation issue might have different reasons. One might be
> > https://fedorahosted.org/sssd/ticket/3103  where SSSD creates a wrong
> > Kerberos configuration snippet. Fixes are available for sssd-1.13 and
> > later. But there might be other reasons as well.
> > 
> > If you don't mind please send the krb5_child.log with debug_level=10
> > covering an authentication attempt with 'krb5_validate = true' and the
> > content of /var/lib/sss/pubconf/krb5.include.d/domain_realm_your_domain.
> 
> Thanks Sumit,
> 
> Info you requested is attached. These logs are from a client machine. I
> confirmed that I could not authenticate with krb5_validate = True and that I
> could authenticate when I switched krb5_validate=false.  I set the value to
> "True", turned up debug logging to 10 and then stopped SSSD service after my
> 3 login tries to try to constrain the log volume.
> 
> Still ended up with 1200+ lines in krb5_child.log though
> 
> Here is the info you requested (sanitized)
> 
> URL to krb5_child.log since it is pretty lengthy:
> -
> http://chrisdag.me/krb5_child.log.txt
> 
> 
> And we actually had 2 domain_realm* files which is I think due to our
> difference in DNS for client hostnames vs DNS for the IPA server:
> Our CAPATH info does look like that SSSD issue you mentioned (ticket 3103)
> ...
> 
> 
> This is domain_realm_companyaws_org:
> --
> [domain_realm]
> .COMPANY.ORG = COMPANY.ORG
> COMPANY.ORG = COMPANY.ORG
> .EAME.COMPANY.ORG = EAME.COMPANY.ORG
> EAME.COMPANY.ORG = EAME.COMPANY.ORG
> .APAC.COMPANY.ORG = APAC.COMPANY.ORG
> APAC.COMPANY.ORG = APAC.COMPANY.ORG
> .LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
> LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
> .NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
> NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
> [capaths]
> COMPANY.ORG = {
>   COMPANYAWS.ORG = COMPANY.ORG
> }
> COMPANYAWS.ORG = {
>   COMPANY.ORG = COMPANY.ORG
> }
> EAME.COMPANY.ORG = {
>   COMPANYAWS.ORG = COMPANY.ORG
> }
> COMPANYAWS.ORG = {
>   EAME.COMPANY.ORG = COMPANY.ORG
> }
> APAC.COMPANY.ORG = {
>   COMPANYAWS.ORG = COMPANY.ORG
> }
> COMPANYAWS.ORG = {
>   APAC.COMPANY.ORG = COMPANY.ORG
> }
> LATAM.COMPANY.ORG = {
>   COMPANYAWS.ORG = COMPANY.ORG
> }
> COMPANYAWS.ORG = {
>   LATAM.COMPANY.ORG = COMPANY.ORG
> }
> NAFTA.COMPANY.ORG = {
>   COMPANYAWS.ORG = COMPANY.ORG
> }
> COMPANYAWS.ORG = {
>   NAFTA.COMPANY.ORG = COMPANY.ORG
> }
> 
> 
> 
> 
> And this is domain_realm_companyidm_org:
> 
> [domain_realm]
> .COMPANY.ORG = COMPANY.ORG
> COMPANY.ORG = COMPANY.ORG
> .EAME.COMPANY.ORG = EAME.COMPANY.ORG
> EAME.COMPANY.ORG = EAME.COMPANY.ORG
> .APAC.COMPANY.ORG = APAC.COMPANY.ORG
> APAC.COMPANY.ORG = APAC.COMPANY.ORG
> .LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
> LATAM.COMPANY.ORG = LATAM.COMPANY.ORG
> .NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
> NAFTA.COMPANY.ORG = NAFTA.COMPANY.ORG
> [capaths]
> COMPANYAWS.ORG = {
>   COMPANYIDM.ORG = COMPANYAWS.ORG
> }
> COMPANYIDM.ORG = {
>   COMPANYAWS.ORG = COMPANYAWS.ORG
> }
> COMPANY.ORG = {
>   COMPANYIDM.ORG = COMPANY.ORG
> }
> COMPANYIDM.ORG = {
>   COMPANY.ORG = COMPANY.ORG
> }
> EAME.COMPANY.ORG = {
>   COMPANYIDM.ORG = COMPANY.ORG
> }
> COMPANYIDM.ORG = {
>   EAME.COMPANY.ORG = COMPANY.ORG
> }
> APAC.COMPANY.ORG = {
>   COMPANYIDM.ORG = COMPANY.ORG
> }
> COMPANYIDM.ORG = {
>   APAC.COMPANY.ORG = COMPANY.ORG
> }
> LATAM.COMPANY.ORG = {
>   COMPANYIDM.ORG = COMPANY.ORG
> }
> COMPANYIDM.ORG = {
>   LATAM.COMPANY.ORG = COMPANY.ORG
> }
> NAFTA.COMPANY.ORG = {
>   COMPANYIDM.ORG = COMPANY.ORG
> }
> COMPANYIDM.ORG = {
>   NAFTA.COMPANY.ORG = COMPANY.ORG
> }


Yes, you are right the capaths are wrong.


Adding:

[capaths]
COMPANYAWS.ORG = {
  COMPANYIDM.ORG = COMPANYAWS.ORG
}
COMPANYIDM.ORG = {
  COMPANYAWS.ORG = COMPANYAWS.ORG
  COMPANY.ORG = COMPANY.ORG
  EAME.COMPANY.ORG = COMPANY.ORG
  APAC.COMPANY.ORG = COMPANY.ORG
  LATAM.COMPANY.ORG = COMPANY.ORG
  NAFTA.COMPANY.ORG = COMPANY.ORG
}
COMPANY.ORG = {
  COMPANYIDM.ORG = COMPANY.ORG
}
EAME.COMPANY.ORG = {
  COMPANYIDM.ORG = COMPANY.O

Re: [Freeipa-users] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts

[Sumit Bose]

On Wed, Dec 07, 2016 at 11:34:12AM -0500, Chris Dagdigian wrote:
> 
> Our problem is largely solved but we are using some "do not use in
> production!" settings so I wanted to both recap our solution and ask some
> follow up questions.
> 
> Our setup:
> -
>  - FreeIPA 4.2 running on CentOS-7 in AWS VPC
>  - Edge-case split DNS setup. Our cloud clients are "company-aws.org" while
> IPA is "company-ipa.org" realm/domain
>  - Massive need to authenticate against AD Forest COMPANY.COM which includes
> a ton of child domains (NAFTA.COMPANY.COM, etc.)
> 
> Problem
> ---
> - AD users are recognized and can be enumerated as long as I use
> usern...@nafta.company.com
> - "su - " works as root to become the AD user
> - All methods that require password check (SSH login mainly) failed
> 
> The breakthrough was the advice from Sumit to add the ldap_user_principal
> and subdomain_inherit settings. The core problem on our end seemed to be
> issues with having the AD user UPN get sorted out. Something was failing
> when u...@nafta.company.com was shortened to u...@company.com and we saw the
> recurring error about " ... UPN is quite different ... "  in the sssd domain
> logs.
> 
> 
> Solution (Server Side)
> -
> In /etc/sssd/sssd.conf:
>  ldap_user_principal = nosuchattr
>  subdomain_inherit = ldap_user_principal
>  krb5_validate = false
> 
> 
> Solution (IPA client side)
> 
> In /etc/sssd/sssd.conf:
>  krb5_validate = false
> 
> 
> I think the main problem is obvious. Even Sumit was clear to state that
> "krb5_validate = false" should be used for testing only.
> 
> However if we remove that setting password checking breaks.
> 
> 
> So the basic "what next question" for the experts is:
> 
> 
> 1. Do we chase down whatever config error we have that requires
> krb5_validate=false ?
> 2. Or do we assume that that problem is related to the UPN problem and
> related AD-across-child-domains that appear to be resolved in IPA-4.4? I
> keep getting the sense that massive AD-related things have been improved
> recently in 4.3 and 4.4
> 
> My gut feeling is that it is our odd UPN issue that is breaking things so
> rather than bend over backwards to try to figure out why krb5_validate=false
> on our IPA-4.2 setup I'm sort of leaning towards trying to go for an upgrade
> to IPA-4.4 and hope that whatever issue forced us to disable krb5_validate
> is resolved in the new updates.

The issues with the UPNs are far from odd and do not need fixing on the
AD side. As said before IPA-4.4 can handle them properly but the
ldap_user_principal/subdomain_inherit workaround for older versions can
be used for production.

> 
> Am I being stupid (again?)  Obviously the krb5_validate=false setting needs
> to be fixed. Just not sure if I should work on a fix within 4.2 or move to
> 4.4 and see if it gets resolved as part of other changes.

The validation issue might have different reasons. One might be
https://fedorahosted.org/sssd/ticket/3103 where SSSD creates a wrong
Kerberos configuration snippet. Fixes are available for sssd-1.13 and
later. But there might be other reasons as well.

If you don't mind please send the krb5_child.log with debug_level=10
covering an authentication attempt with 'krb5_validate = true' and the
content of /var/lib/sss/pubconf/krb5.include.d/domain_realm_your_domain.

bye,
Sumit
> 
> 
> Regards,
> Chris
> 
> 
> 
> 
> 
> 

-- 
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] Debugging failed password checks (SSH) for AD users at the other end of 1-way trusts

[Sumit Bose]

On Tue, Dec 06, 2016 at 03:17:33PM -0500, List dedicated to discussions about 
use, configuration and deployment of the IPA server. wrote:
> 
> Appreciate the assistance!
> 
> Is there a better debug level balance than 10 for this sort of situation?
> The domain logs were several hundred MBs by the time I started looking for
> useful info if there is a different level I can use that would better at
> producing actionable error/log messages I'll gladly switch ...
> 
> 
> List dedicated to discussions about use, configuration and deployment of the
> IPA server. wrote:
> > > (Tue Dec  6 15:36:48 2016) [[sssd[krb5_child[4005 [main] (0x0400):
> > > >  krb5_child started.
> > > >  (Tue Dec  6 15:36:48 2016) [[sssd[krb5_child[4005 [unpack_buffer]
> > > >  (0x1000): total buffer size: [158]
> > > >  (Tue Dec  6 15:36:48 2016) [[sssd[krb5_child[4005 [unpack_buffer]
> > > >  (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [false]
> > > >  enterprise principal [false] offline [true] UPN [u...@company.org]
> > 
> >^^^
> > 
> > The backend switch to offline mode, please send the SSSD domain logs
> > around this time as well. If possible please start about 5 minutes
> > earlier.
> > 
> > bye,
> > Sumit
> 
> I searched through the massive SSSD domain logs and had trouble finding the
> right area so here are the lines surrounding my own username when I tried to
> authenticate via SSH using AD credentials:
> 
> 
...
> 
...
> [sss_krb5_expire_callback_func] (0x2000): exp_time: [2742397]
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406 [get_and_save_tgt]
> (0x0100): TGT validation is disabled.
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406
> [sss_get_ccache_name_for_principal] (0x4000): Location:
> [KEYRING:persistent:1843770609]
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406
> [sss_get_ccache_name_for_principal] (0x4000): tmp_ccname:
> [KEYRING:persistent:1843770609:krb_ccache_OVBc5zF]
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406 [create_ccache]
> (0x4000): Initializing ccache of type [KEYRING]
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406 [create_ccache]
> (0x4000): CC supports switch
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406 [create_ccache]
> (0x4000): returning: 0
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406
> [safe_remove_old_ccache_file] (0x0400): New and old ccache file are the
> same, none will be deleted.
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406 [k5c_send_data]
> (0x0200): Received error code 0
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406
> [pack_response_packet] (0x2000): response packet size: [144]
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406 [k5c_send_data]
> (0x4000): Response sent.
> (Tue Dec  6 19:57:11 2016) [[sssd[krb5_child[12406 [main] (0x0400):
> krb5_child completed successfully
...
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417
> [sss_krb5_expire_callback_func] (0x2000): exp_time: [2742394]
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417 [get_and_save_tgt]
> (0x0100): TGT validation is disabled.
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417
> [sss_get_ccache_name_for_principal] (0x4000): Location:
> [KEYRING:persistent:1843770609]
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417
> [sss_get_ccache_name_for_principal] (0x4000): tmp_ccname:
> [KEYRING:persistent:1843770609:krb_ccache_OVBc5zF]
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417 [create_ccache]
> (0x4000): Initializing ccache of type [KEYRING]
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417 [create_ccache]
> (0x4000): CC supports switch
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417 [create_ccache]
> (0x4000): returning: 0
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417
> [safe_remove_old_ccache_file] (0x0400): New and old ccache file are the
> same, none will be deleted.
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417 [k5c_send_data]
> (0x0200): Received error code 0
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417
> [pack_response_packet] (0x2000): response packet size: [144]
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417 [k5c_send_data]
> (0x4000): Response sent.
> (Tue Dec  6 19:57:14 2016) [[sssd[krb5_child[12417 [main] (0x0400):
> krb5_child completed successfully
> 
> 

Both authentications where successful against the backend. For the logs
it looks like you use an alternative domain suffix on the AD side so
that all user if other domains in the forest can use the forest root
suffix as realm, in the user principal (u...@nafta.company.org ->
u...@company.org).

I would expect that there are messages like "UPN used in the request
...differ by more than just the case." in the domain log at 'Tue Dec  6
19:57:11' and 'Tue Dec  6 19:57:14'.

If that's the case updating to 4.4 would help because in this release
IPA can forward the enterprise 

Re: [Freeipa-users] Mapping users from AD to IPA KDC

[Sumit Bose]

On Fri, Dec 02, 2016 at 08:30:28AM -0500, TomK wrote:
> Hey All,
> 
> I've successfully mapped the nixadmins to the external group
> nixadmins_external.  However no users in that group make it over to Free IPA
> that I can see.
> 
> ipa group-add-member nixadmins_external --external "nixadmins"
> 
> Windows AD users, 3 of them, are in the windows AD group nixadmins. However
> I can't port them over.
> 
> These accounts have UNIX attributes assigned to them.
> 
> Question that I have and can't find, should I be seeing these users in the
> mapped groups above?  ( ie within the GUI should I see any users listed from
> AD DC in nixadmins or nixadmins_external? )

no, the GUI won't show them. Calling 'id user_from_nixadmins@ad.domain'
should show that nixadmins_external is a member of that group. With
recent version of SSSD 'getent group nixadmins_external' should list the
users from nixadmins as well, older versions might miss them.

HTH

bye,
Sumit

> 
> If there is an issue and I'm just not picking it out from the debug logs,
> what to look for?  Is there anything more I need to do on the Windows side
> that I haven't found on the existing pages?
> 
> 
> # ipa group-add-member nixadmins_external --external "nixadmins"
> [member user]:
> [member group]:
>   Group name: nixadmins_external
>   Description: NIX Admins External map
>   External member: S-1-5-21-3418825849-1633701630-2291579631-1006
>   Member groups: nixadmins
>   Member of groups: nixadmins
>   Indirect Member groups: nixadmins_external
> -
> Number of members added 1
> -
> #
> 
> 
> # ipa trustdomain-find abc.xyz
>   Domain name: abc.xyz
>   Domain NetBIOS name: ABC
>   Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517
>   Domain enabled: True
> 
> Number of entries returned 1
> 
> #
> 
> 
> [realms]
>  DOM.ABC.XYZ = {
> .
> .
> .
>   auth_to_local = RULE:[1:$1@$0](^.*@ABC.XYZ$)s/@ABC.XYZ/@abc.xyz/
>   auth_to_local = DEFAULT
> }
> 
> 
> # ipa trust-fetch-domains abc.xyz
> 
> List of trust domains successfully refreshed. Use trustdomain-find command
> to list them.
> 
> 
> Number of entries returned 0
> 
> [root@idmipa01 sssd]# ipa trustdomain-find abc.xyz
>   Domain name: abc.xyz
>   Domain NetBIOS name: ABC
>   Domain Security Identifier: S-1-5-21-1803828911-4163023034-2461700517
>   Domain enabled: True
> 
> Number of entries returned 1
> 
> 
> 
> # ipa trust-fetch-domains abc.xyz
> 
> List of trust domains successfully refreshed. Use trustdomain-find command
> to list them.
> 
> 
> Number of entries returned 0
> 
> #
> 
> 
> The following command successfully returns all AD objects under the Users
> cn.
> 
> # ldapsearch -x -h 192.168.0.3 -D "t...@abc.xyz" -W -b
> "cn=users,dc=abc,dc=xyz" -s sub "(cn=*)" cn mail sn
> 
> 
> -- 
> Cheers,
> Tom K.
> -
> 
> Living on earth is expensive, but it includes a free trip around the sun.
> 
> -- 
> 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] Mac OS X 10.12 Smart card authentication to FreeIPA server.

[Sumit Bose]

On Tue, Nov 29, 2016 at 06:21:11PM +, Daly, John L CIV NAVAIR, 4GD 
wrote:
> Greetings,
> I thumbed through the archive, but didn't find an answer.  If I missed it, 
> perhaps someone will be kind enough to point me in the right direction.
> 
> I'm testing replacing our OpenDirectory server with a FreeIPA server for 
> authenticating our Mac systems.  So far, I have the server and client running 
> in a virtual machine (FreeIPA running on CentOS 7, Mac is MacOS 10.12.1), 
> and, following a number of instructions found on the web, they are talking to 
> each other and I can log in from the Mac client to the FreeIPA server with a 
> user account on the FreeIPA server.
> 
> The final step in this is that I need to use smart card authentication 
> instead of username/password.  I have managed to get the smart card's 
> certificate added to the user account on the FreeIPA server, but that's as 
> far as I've managed.
> 
> In MacOS 10.7-10.11, the method of getting smart card authorization to work 
> is to get the hash of the certificate on the smart card and then add that to 
> AuthenticationAuthority in Directory Utility as ;pubkeyhash;
> In 10.12, it will actually ask you if you want to pair the smart card with 
> the account, and if so, in the background it adds the hash as 
> ;tokenIdentity; to AuthenticationAuthority (but it only 
> does that to local accounts.  to do it in Open Directory, you have to add it 
> manually still)
> 
> In my ignorance, I'm guessing that I just somehow need to map the certificate 
> that's been added to the user account in FreeIPA to AuthenticationAuthority 
> in DirectoryUtility.  Right now the only thing mapped in the bind for 
> AuthenticationAuthority is uid.

Can you send me an example of an user object from OpenDirectory which
has all the needed attributes to make Smartcard authentication work?

bye,
Sumit

> 
> Could someone tell me what map I would need to make when setting up the bind 
> to make this work? Or if I'm totally heading in the wrong direction, could 
> someone send me in the right direction?
> 
> Nathan Kinder's blog was very helpful, but he mentions telling how to 
> actually set up login on the next installment, and that was over a year ago 
> and there's no next installment.  Most of what I've been able to find covers 
> how to use sssd to get a linux machine to authenticate with the smartcard to 
> FreeIPA, but I haven't been able to translate that to getting the Mac to 
> authenticate.
> 
> Thank you,
> John
> 
> -- 
> 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] This again :) - ssh authentication for users in complex AD forest - where am I going wrong?

[Sumit Bose]

On Wed, Nov 23, 2016 at 07:38:49AM -0500, Chris Dagdigian wrote:
> 
> < huge log sample deleted >
> 
> Sumit Bose wrote:
> > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369 [validate_tgt]
> > (0x0020): TGT failed verification using key for
> > [host/usaeilvdip001.company-aws@company-idm.org].
> > 
> > ok, it is the ticket validation which fails. You can get around this for
> > testing by setting 'krb5_validate = false' in the [domain/...] section
> > of sssd.conf. But please use this only for testing because this error
> > indicates that there are issues in your setup/configuration.
> 
> Much appreciated. Will test today.
> > But your host principal
> > host/usaeilvdip001.company-aws@company-idm.org looks odd as well.
> > Why is the host in the AD DNS domain, this calls for trouble.
> > Additionally I wonder why the realm part '@company-idm.org' was created
> > in lower-case while joining the IPA this should be created upper-case.
> > Or is this all due to sanitation?
> 
> { Capitalization problem was a sanitation error }
> 
> At the time we set up the IPA environment the only AD domain we had
> administrative control over
> was already in use and could not easily be reconfigured to meet the best
> practices for having an
> IPA server sit in the same domain name and realm
> 
> After reading the documentation and a lot of posts on redhat.com we decided
> that the IPA server
> would have to be in a completely new autonomous domain name, DNS zone and
> Kerberos realm. The
> IPA instructions (and ipa-client-install options) all seem to indicate that
> although not a best practice it
> is something that was supported although there is a loss of functionality to
> be expected.

NO. It is the other way round.

It is _not_ recommended and will not even work properly to use the same
DNS domain for IPA and AD. Even worse with using the same realm for
both, this cannot work at all.

It is required to have a different realm name for the IPA domain and it
is important to use a different DNS domain as well (a bit is possible
with hosts in the same DNS domain but you loose functionality here).

Where did you find the recommendation to user the same DNS domain and
realm?

bye,
Sumit

> 
> So we run servers as FQDN members of company-aws.org but they are IPA
> clients of company-ipa.org
> 
> My understanding is that if we:
> 
>  1. Bind a Linux IPA client to company-ipa.com
>  2. But configure the Linux client to have a hostname of
> client.company-aws.com
> 
> .. then what we primarily lose is kerberos related service functionality for
> logged-in users
> 
> Since our core need was for AD password authentication and RBAC control over
> Linux hosts we
> decided to move forward with this odd config.
> 
> Would be greatly interested if I'm way off base on use of totally autonomous
> IPA realms and domain names.
> 
> > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369 [get_and_save_tgt]
> > > (0x0020): 1242: [-1765328377][Server not found in Kerberos database]
> > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369 [map_krb5_error]
> > > (0x0020): 1303: [-1765328377][Server not found in Kerberos database]
> > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369 [k5c_send_data]
> > > (0x0200): Received error code 1432158209
> > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369 
> > > [pack_response_packet]
> > > (0x2000): response packet size: [20]
> > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369 [k5c_send_data]
> > > (0x4000): Response sent.
> > > (Tue Nov 22 16:02:48 2016) [[sssd[krb5_child[4369 [main] (0x0400):
> > > krb5_child completed successfully
> > > [root@usaeilvdip001 sssd]#
> > > 
> > > 
> > 
> > The logs indicate that the user actually come from the member domain in
> > the forest: usern...@nafta.company.org. But the [capath] section you
> > added to krb5.conf only contains the forest root.
> > 
> > > COMPANY-AWS.ORG = {
> > > 
> > >COMPANY-IDM.ORG = COMPANY-AWS.ORG
> > > 
> > > }
> > > 
> > > COMPANY-IDM.ORG = {
> > > 
> > >COMPANY-AWS.ORG = COMPANY-AWS.ORG
> > > 
> > > }
> > > 
> > 
> > Please try to add the member domain as well. The result might look like
> > this: (assuming COMPANY-AWS is the forest root, NAFTA is the member
> > domain and COMPANY-IDM is the IPA domain)
> > 
> > COMPANY-AWS.ORG = {
> > 
> >COMPANY-IDM.ORG = COMPANY-AWS.ORG
> > 
> > }
> > 
> > COMPANY-IDM.ORG = {
>

Re: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong?

[Sumit Bose]

On Tue, Nov 22, 2016 at 11:17:37AM -0500, Chris Dagdigian wrote:
> 
> 
> Sumit Bose wrote:
> > Please send the full krb5_child.log with debug_level=10 in the
> > [domain/...] section of sssd.conf. My current guess is the ticket
> > validation fails. Which version of SSSD are you using?
> > 
> > bye,
> > Sumit
> 
> 
> This is a CentOS 7 client running SSSD-1.13
> 
> Thank you. Lots of interesting info in this log. I've sanitized hostnames,
> username and IP but that was it:
> 
> ### log data below 
> 
> 
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [main] (0x0400):
> krb5_child started.
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [unpack_buffer]
> (0x1000): total buffer size: [158]
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [unpack_buffer]
> (0x0100): cmd [241] uid [1843770609] gid [1843770609] validate [true]
> enterprise principal [false] offline [false] UPN [usern...@company.org]
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [unpack_buffer]
> (0x0100): ccname: [KEYRING:persistent:1843770609] old_ccname:
> [KEYRING:persistent:1843770609] keytab: [/etc/krb5.keytab]
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [switch_creds]
> (0x0200): Switch user to [1843770609][1843770609].
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369
> [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired.
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [switch_creds]
> (0x0200): Switch user to [0][0].
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [k5c_check_old_ccache]
> (0x4000): Ccache_file is [KEYRING:persistent:1843770609] and is not active
> and TGT is  valid.
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [k5c_precreate_ccache]
> (0x4000): Recreating ccache
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [k5c_setup_fast]
> (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to
> [host/usaeilvdip001.company-aws@company-idm.org]
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369
> [find_principal_in_keytab] (0x4000): Trying to find principal
> host/usaeilvdip001.company-aws@company-idm.org in keytab.
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [match_principal]
> (0x1000): Principal matched to the sample
> (host/usaeilvdip001.company-aws@company-idm.org).
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [check_fast_ccache]
> (0x0200): FAST TGT is still valid.
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [become_user]
> (0x0200): Trying to become user [1843770609][1843770609].
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [main] (0x2000):
> Running as [1843770609][1843770609].
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [k5c_setup] (0x2000):
> Running as [1843770609][1843770609].
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [set_lifetime_options]
> (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment.
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [set_lifetime_options]
> (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment.
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369
> [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true]
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [main] (0x0400): Will
> perform online auth
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [tgt_req_child]
> (0x1000): Attempting to get a TGT
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369 [get_and_save_tgt]
> (0x0400): Attempting kinit for realm [COMPANY.ORG]
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369
> [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899271: Getting
> initial credentials for usern...@company.org
> 
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369
> [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899337: FAST armor
> ccache: MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org
> 
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369
> [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899368: Retrieving
> host/usaeilvdip001.company-aws@company-idm.org -> 
> krb5_ccache_conf_data/fast_avail/krbtgt\/COMPANY.ORG\@COMPANY.ORG@X-CACHECONF:
> from MEMORY:/var/lib/sss/db/fast_ccache_company-idm.org with result:
> -1765328243/Matching credential not found
> 
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369
> [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899415: Sending
> request (169 bytes) to COMPANY.ORG
> 
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369
> [sss_child_krb5_trace_cb] (0x4000): [4369] 1479830567.899575: Resolving
> hostname COMPANY.ORG
> 
> (Tue Nov 22 16:02:47 2016) [[sssd[krb5_child[4369
> [sss_child_krb

Re: [Freeipa-users] This again :) - ssh authentication for users in complex AD forest - where am I going wrong?

[Sumit Bose]

On Tue, Nov 22, 2016 at 10:37:06AM -0500, Chris Dagdigian wrote:
> Upfront
>  - I know this question is fairly common and I do read the list and
> archives, honest!
>  - I'm following the SSSD troubleshooting wiki and running with debug
> settings for PAM and SSH
>  - Still not quite sure where my config problem lies
> 
>  - I see "Server not found in kerberos database" in /var/log/messages so I
> think I have a simple /etc/krb5.conf error; possibly a very simple root
> cause like my client can't use DNS to autodiscover a KDC. Not 100% sure how
> to confirm that

Please send the full krb5_child.log with debug_level=10 in the
[domain/...] section of sssd.conf. My current guess is the ticket
validation fails. Which version of SSSD are you using?

bye,
Sumit

> 
> 
> Setup:
> 
>  - We run an IPA server at COMPANY-IDM.ORG with the goal of using it as
> "glue" for multiple Active Directory relationships
>  - Successful trusts made with a number of test AD forest and domains,
> including SSH logins all working fine
>  - Got the Trust set up to the real COMPANY.ORG forest last night
>  - Trust to COMPANY.ORG went in just fine
>  - We can fetch trusted domains through COMPANY.ORG and see all the children
> we expect to see (excellent!)
> 
> Situation:
> 
>  - I can resolve usern...@nafta.company.org on IPA server and bound client
>  - I can "kinit usern...@nafta.company.org" on the IPA server and ipa
> managed client
>  - From root I can "sudo usern...@nafta.company.org" on IPA and client
> server and end up as proper user in proper homedir
>  - I can login via SSH to IPA server and client machines as
> u...@testdomain.org
>  - ping COMPANY.ORG and NAFTA.COMPANY.ORG resolves to the remote AD servers
> so I think DNS forwarding is OK
> 
> BUT -- any sort of "ssh usern...@nafta.company.org" fails, client sees
> variations of "permission denied"; nothing super useful so far in security,
> ssh or sssd logs
> 
> So basically password checking is broken for the actual COMPANY.ORG trust we
> set up last night.
> 
> When I had this issue with our test AD domains I think the answer was that
> "client could not discover which KDC to contact for password checking" so
> our response was to customize the krb5.conf file to explicitly enable DNS
> lookups..
> 
> This feels to me like either I've messed up sssd.conf or perhaps more likely
> I'm missing a config setting in krb5.conf that is specific to password
> checking for COMPANY.ORG and NAFTA.COMPANY.org
> 
> 
> We are running in AWS with VPC Flow Logs enabled and there are no obvious
> REJECT logs showing blockage of traffic to KDC or Domain Controllers
> 
> 
> Seeking tips and any guidance people can provide!
> 
> Without burying people in log and config data, here is what I think the
> relevant info on our side is:
> 
> /etc/krb5.conf (IPA client)
> -
> 
> [libdefaults]
> 
>   default_realm = COMPANY-IDM.ORG
>   dns_lookup_realm = true
>   dns_lookup_kdc = true
>   rdns = false
>   ticket_lifetime = 24h
>   forwardable = yes
>   udp_preference_limit = 0
>   default_ccache_name = KEYRING:persistent:%{uid}
> 
> [realms]
> 
>   COMPANY-IDM.ORG = {
> kdc = usaeilidmp001.company-idm.org:88
> master_kdc = usaeilidmp001.company-idm.org:88
> admin_server = usaeilidmp001.company-idm.org:749
> default_domain = company-idm.org
> pkinit_anchors = FILE:/etc/ipa/ca.crt
> 
>   }
> 
> [domain_realm]
> 
> ipa-client.company-aws.org = COMPANY-IDM.ORG
> 
> [capaths]
> 
> COMPANY-AWS.ORG = {
> 
>   COMPANY-IDM.ORG = COMPANY-AWS.ORG
> 
> }
> 
> COMPANY-IDM.ORG = {
> 
>   COMPANY-AWS.ORG = COMPANY-AWS.ORG
> 
> }
> 
> 
> 
> Here is /etc/sssd/sssd.conf from an IPA client:
> -
> 
> [domain/company-idm.org]
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = company-idm.org
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ldap_tls_cacert = /etc/ipa/ca.crt
> ipa_hostname =  client.company-aws.org
> chpass_provider = ipa
> ipa_server = _srv_, usaeilidmp001.company-idm.org
> dns_discovery_domain = company-idm.org
> 
> [sssd]
> 
> debug_level = 6
> services = nss, sudo, pam, ssh
> config_file_version = 2
> 
> domains = company-idm.org
> 
> [nss]
> 
> homedir_substring = /home
> 
> [pam]
> 
> debug_level = 10
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> 
> debug_level = 6
> 
> [pac]
> 
> [ifp]
> 
> 
> 
> And finally after turning on debug here is some output from sssd_pam.log
> with debug mode set:
> ---
> 
> (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_check_user_search] (0x0400):
> Returning info for user [usern...@nafta.company.org]
> (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pd_set_primary_name] (0x0400):
> User's primary name is usern...@nafta.company.org (Tue Nov 22 14:55:07 2016)
> [sssd[pam]] [pam_initgr_cache_set] (0x2000): [usern...@nafta.company.org]
> added to PAM initgroup cache
> (Tue Nov 22 14:55:07 2016) [sssd[pam]] [pam_dp_send_req] 

Re: [Freeipa-users] Freeipa-users Digest, Vol 100, Issue 48

[Sumit Bose]

On Fri, Nov 18, 2016 at 12:09:41PM +0100, rajat gupta wrote:
> Hi,
> 
> 
> I removed the pam_winbind module. User are able to login now. But some time
> they are not. Below are logs when user are not able to login.  Also SSH

see comment at the end of the email.

> login  is very slow for AD user. I am using sssd 1.4

Please note that SSSD does more than a simple kinit, it will validate
the returned TGT of the user by requesting a service ticket for a
service form the local keytab. This requires for AD users at least one
round trip to an AD DC and another one to the IPA server. If the AD user
is coming from a member domain in the AD forest and not from the forest
root there are even more round trips. 


> =
> rpm -qa | grep sssd
> sssd-krb5-common-1.14.0-43.el7.x86_64
> python-sssdconfig-1.14.0-43.el7.noarch
> sssd-ldap-1.14.0-43.el7.x86_64
> sssd-client-1.14.0-43.el7.x86_64
> sssd-ipa-1.14.0-43.el7.x86_64
> sssd-proxy-1.14.0-43.el7.x86_64
> sssd-common-1.14.0-43.el7.x86_64
> sssd-ad-1.14.0-43.el7.x86_64
> sssd-1.14.0-43.el7.x86_64
> sssd-krb5-1.14.0-43.el7.x86_64
> sssd-common-pac-1.14.0-43.el7.x86_64
> ===
> 
> =
> My sssd.conf on ipa clinet
> 
> cat /etc/sssd/sssd.conf
> [domain/ipa.preprod.local]
> 
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = ipa.ipadomain.local
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = ilt-gif-ipa02.ipa.ipadomain.local
> chpass_provider = ipa
> ipa_server = _srv_, ilt-gif-ipa01.ipa.ipadomain.local
> ldap_tls_cacert = /etc/ipa/ca.crt
> debug_level = 10
> krb5_use_enterprise_principal = True
> 
> 
> 
> [sssd]
> default_domain_suffix = corp.addomain.com
> services = nss, sudo, pam, ssh
> 
> domains = ipa.ipadomain.local
> debug_level = 10
> 
> [nss]
> override_homedir = /home/%u
> debug_level = 10
> 
> 
> 
> [pam]
> debug_level = 10
> 
> 
> [sudo]
> 
> [autofs]
> 
> [ssh]
> debug_level = 10
> 
> 
> [pac]
> 
> [ifp]
> ==
> 
> 
> 
...
> (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084 [main] (0x0400):
> krb5_child started.
> (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084 [unpack_buffer]
> (0x1000): total buffer size: [168]
> (Fri Nov 18 11:46:25 2016) [[sssd[krb5_child[16084 [unpack_buffer]
> (0x0100): cmd [241] uid [1007629326] gid [1007629326] validate [true]
> enterprise principal [false] offline [true] UPN [subarancha...@mydomaon.com]

SSSD is in offline mode again, if the user never successfully login in
with a password authentication will fail. You should check the SSSD
domain log to figure out why SSSD switches into offline mode.

HTH

bye,
Sumit

-- 
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 failed with 'ldap_sasl_bindfailed(-2)[Localerror]'

[Sumit Bose]

On Thu, Nov 10, 2016 at 07:19:09PM +0800, Matrix wrote:
> Hi, Sumit
> 
> I have checked, and did not find anything more:
> 
> error logs from /var/log/dirsrv/slapd-EXAMPLE-NET/access: 
> ...
> [10/Nov/2016:10:46:58 +] conn=816560 fd=189 slot=189 connection from 
> 10.2.3.32 to 10.2.1.250
> [10/Nov/2016:10:46:58 +] conn=816560 op=0 BIND dn="" method=sasl 
> version=3 mech=GSSAPI
> [10/Nov/2016:10:46:58 +] conn=816560 op=0 RESULT err=14 tag=97 nentries=0 
> etime=0, SASL bind in progress
> [10/Nov/2016:10:46:58 +] conn=816560 op=-1 fd=189 closed - B1

Sorry, I still have no idea, maybe running ldapwhoami with '-d -1' might
help to identify which step is failing.

bye,
Sumit

> 
> ...
> 
> Matrix
> 
> 
> -- Original --
> From:  "Sumit Bose";<sb...@redhat.com>;
> Date:  Thu, Nov 10, 2016 07:13 PM
> To:  "Matrix"<matrix...@qq.com>; 
> Cc:  "Sumit Bose"<sb...@redhat.com>; 
> "freeipa-users"<freeipa-users@redhat.com>; 
> Subject:  Re: [Freeipa-users] sssd failed with 
> 'ldap_sasl_bindfailed(-2)[Localerror]'
> 
> 
> 
> On Thu, Nov 10, 2016 at 06:48:54PM +0800, Matrix wrote:
> > Hi, Sumit
> > 
> > Thanks for your reply
> > 
> > I have tried. still failed
> 
> Do you see any related messages on the LDAP server side?
> 
> bye,
> Sumit
> 
> > 
> > # cat /etc/openldap/ldap.conf  | grep -v ^#
> > 
> > URI ldap://ipaslave.stg.example.net
> > BASE dc=example,dc=net
> > TLS_CACERT /etc/ipa/ca.crt
> > SASL_MECH GSSAPI
> > TLS_REQCERT allow
> > SASL_NOCANON on
> > 
> > 
> > # cat /etc/krb5.conf| grep rdns
> >   rdns = false
> > 
> > Matrix
> > 
> > -- Original --
> > From:  "Sumit Bose";<sb...@redhat.com>;
> > Date:  Thu, Nov 10, 2016 06:32 PM
> > To:  "freeipa-users"<freeipa-users@redhat.com>; 
> > 
> > Subject:  Re: [Freeipa-users] sssd failed with 'ldap_sasl_bind 
> > failed(-2)[Localerror]'
> > 
> > 
> > 
> > On Thu, Nov 10, 2016 at 05:22:26PM +0800, Matrix wrote:
> > > debug steps have been tried: 
> > > 
> > > 1 kinit is workable: 
> > > # /usr/kerberos/bin/kinit -k host/client02.stg.example@example.net
> > > 
> > > # /usr/kerberos/bin/klist
> > > Ticket cache: FILE:/tmp/krb5cc_0
> > > Default principal: host/client02.stg.example@example.net
> > > 
> > > Valid starting ExpiresService principal
> > > 11/10/16 09:18:00  11/11/16 09:17:35  krbtgt/example@example.net
> > > 
> > > Kerberos 4 ticket cache: /tmp/tkt0
> > > klist: You have no tickets cached
> > > 
> > > 2 ldapwhoami with krb auth failed. 
> > > 
> > > # ldapwhoami -Y GSSAPI -h ipaslave.stg.example.net
> > > SASL/GSSAPI authentication started
> > > ldap_sasl_interactive_bind_s: Local error (-2)
> > > additional info: SASL(-1): generic failure: GSSAPI Error: 
> > > Unspecified GSS failure.  Minor code may provide more information (Mutual 
> > > authentication failed)
> > > 
> > 
> > Have you made sure that canonicalizing is disabled, i.e.
> > /etc/krb5.conf: 
> > [libdefaults]
> >  ...
> >  rdns = false
> >  ...
> > 
> > /etc/openldap/ldap.conf
> > ...
> > SASL_NOCANONon
> > ...
> > 
> > HTH
> > 
> > bye,
> > Sumit
> > 
> > > 
> > > Matrix
> > > 
> > > -- Original --
> > > From:  "Matrix";<matrix...@qq.com>;
> > > Date:  Thu, Nov 10, 2016 02:11 PM
> > > To:  "freeipa-users"<freeipa-users@redhat.com>; 
> > > 
> > > Subject:  [Freeipa-users] sssd failed with 'ldap_sasl_bind failed 
> > > (-2)[Localerror]'
> > > 
> > > 
> > > 
> > > Hi, 
> > > 
> > > I have installed sssd in a RHEL5 client. 
> > > 
> > > ipa-client/sssd version:
> > > ipa-client-2.1.3-7.el5
> > > sssd-client-1.5.1-71.el5
> > > sssd-1.5.1-71.el5
> > > 
> > > sssd failed to get ipa user info with 'ldap_sasl_bind failed (-2)[Local 
> > > error]'. 
> > > 
> > > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] 
> > > (4): Executing sasl bind mech: GSSAPI, user: host/client02.stg.example.net
> > > (Thu Nov 10 0

Re: [Freeipa-users] Freeipa-users Digest, Vol 100, Issue 48

[Sumit Bose]

On Wed, Nov 16, 2016 at 02:31:52PM +0100, rajat gupta wrote:
> Thanks, It is working for few user but not for every one. I have cleared
> the sssd cache as well.
> =
> /var/log/secure
> 
> Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_sss(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=146.213.0.134
> user=kb1980
> Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_sss(sshd:auth): received for
> user kb1980: 6 (Permission denied)
> Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): getting
> password (0x0010)
> Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth):
> pam_get_item returned a password
> Nov 16 14:06:39 ipa-clinet1 sshd[6852]: pam_winbind(sshd:auth): internal
> module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'kb1980')
> Nov 16 14:06:39 ipa-clinet1 sshd[6852]: Failed password for kb1980 from
> 146.213.0.134 port 51114 ssh2
> Nov 16 14:06:48 ipa-clinet1 sshd[6852]: Connection closed by 146.213.0.134
> [preauth]
> Nov 16 14:07:07 ipa-clinet1 sshd[3677]: pam_unix(sshd:session): session
> closed for user kb1980
> 
> 
> krb5_child.log
> 
> (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879 [main] (0x0400):
> krb5_child started.
> (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879 [unpack_buffer]
> (0x1000): total buffer size: [54]
> (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6879 [unpack_buffer]
> (0x0100): cmd [249] uid [1007628631] gid [1007628631] validate [true]
> enterprise principal [false] offline [true] UPN [karan.b@MYDOMAIN COM]
...
> (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880 [main] (0x0400):
> krb5_child started.
> (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880 [unpack_buffer]
> (0x1000): total buffer size: [159]
> (Wed Nov 16 14:06:33 2016) [[sssd[krb5_child[6880 [unpack_buffer]
> (0x0100): cmd [241] uid [1007628631] gid [1007628631] validate [true]
> enterprise principal [false] offline [true] UPN [karan.b@MYDOMAIN COM]
...
> (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881 [main] (0x0400):
> krb5_child started.
> (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881 [unpack_buffer]
> (0x1000): total buffer size: [54]
> (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6881 [unpack_buffer]
> (0x0100): cmd [249] uid [1007628631] gid [1007628631] validate [true]
> enterprise principal [false] offline [true] UPN [karan.b@MYDOMAIN COM]
...
> (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882 [main] (0x0400):
> krb5_child started.
> (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882 [unpack_buffer]
> (0x1000): total buffer size: [159]
> (Wed Nov 16 14:06:39 2016) [[sssd[krb5_child[6882 [unpack_buffer]
> (0x0100): cmd [241] uid [1007628631] gid [1007628631] validate [true]
> enterprise principal [false] offline [true] UPN [karan.b@MYDOMAIN COM]

As you can see all attempts where done while SSSD is offline ("offline
[true]") and enterprise principal is still set to 'false' so it is
expected that authentication fails as long as there are no cached
credentials, i.e. the user once authenticated successful and
'cache_credentials = True' is set in sssd.conf.

Please check in the domain log why SSSD is offline and make sure
enterprise principal is set to 'True' as described in my last email.

HTH

bye,
Sumit

-- 
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-users Digest, Vol 100, Issue 49

[Sumit Bose]

On Wed, Nov 16, 2016 at 03:06:34PM +0100, rajat gupta wrote:
> Hi sumit,
> 
> you mean to say  these?
> 
> ]# grep pam_winbind /etc/pam.d/password-auth
> authsufficientpam_winbind.so use_first_pass
> account [default=bad success=ok user_unknown=ignore] pam_winbind.so
> passwordsufficientpam_winbind.so use_authtok
> session optional  pam_winbind.so

yes, in general pam_winbind is not needed on IPA clients, is there a
reason why you added it?

Btw, please try to reply to the thread, otherwise is it hard to find you
replies.

bye,
Sumit

> 
> 
> On Wed, Nov 16, 2016 at 2:32 PM, <freeipa-users-requ...@redhat.com> wrote:
> 
> > Send Freeipa-users mailing list submissions to
> > freeipa-users@redhat.com
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> > or, via email, send a message with subject or body 'help' to
> > freeipa-users-requ...@redhat.com
> >
> > You can reach the person managing the list at
> > freeipa-users-ow...@redhat.com
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Freeipa-users digest..."
> >
> >
> > Today's Topics:
> >
> >1. minimise impact compromised host (Stijn De Weirdt)
> >2. Re: pam_winbind(sshd:auth): pam_get_item returned a password
> >   (Sumit Bose)
> >3. Re: Freeipa-users Digest, Vol 100, Issue 48 (rajat gupta)
> >
> >
> > --
> >
> > Message: 1
> > Date: Wed, 16 Nov 2016 14:01:09 +0100
> > From: Stijn De Weirdt <stijn.dewei...@ugent.be>
> > To: freeipa-users@redhat.com
> > Subject: [Freeipa-users] minimise impact compromised host
> > Message-ID: <ff5882de-4ce0-dcfb-ce37-dba2d47ca...@ugent.be>
> > Content-Type: text/plain; charset=utf-8
> >
> > hi all,
> >
> > we are looking how to configure whatever relevant policy to minimise the
> > impact of compromised IPA hosts (ie servers with a valid host keytab).
> >
> > in particular, it looks like it possible to retrieve any user token once
> > you have access to a valid host keytab.
> >
> > we're aware that the default IPA policies are wide open, but we are
> > looking how to limit this. for us, there's no need that a hostkeytab can
> > retrieve tokens for anything except the services on that host.
> >
> >
> > stijn
> >
> >
> >
> > --
> >
> > Message: 2
> > Date: Wed, 16 Nov 2016 14:25:00 +0100
> > From: Sumit Bose <sb...@redhat.com>
> > To: freeipa-users@redhat.com
> > Subject: Re: [Freeipa-users] pam_winbind(sshd:auth): pam_get_item
> > returned a password
> > Message-ID:
> > <20161116132500.GO28171@p.Speedport_W_724V_Typ_A_05011603_00_009>
> > Content-Type: text/plain; charset=us-ascii
> >
> > On Wed, Nov 16, 2016 at 01:01:59PM +0100, Sumit Bose wrote:
> > > On Wed, Nov 16, 2016 at 12:49:59PM +0100, rajat gupta wrote:
> > > > I am using FreeIPA  version 4.4.0 Active Directory trust setup. And on
> > > > Active Directory side I am using UPN suffix.
> > > > Following are my domain setup.
> > > >
> > > > AD DOMANIN :- corp.addomain.com
> > > > UPN suffix :- usern...@mydomain.com
> > > > IPA DOMAIN :- ipa.ipadomain.local
> > > > IPA server hostname:- ilt-gif-ipa01.ipa.ipadomain.local
> > >
> > > When you call 'ipa trust-find' on the IPA server do you see the
> > > mydomain.com UPN suffix listed, like e.g.:
> > >
> > > # ipa trust-find
> > > ---
> > > 1 trust matched
> > > ---
> > >   Realm-Name: ad.devel
> > >   Domain NetBIOS name: AD
> > >   Domain Security Identifier: S-1-5-21-3692237560-1981608775-3610128199
> > >   Trust type: Active Directory domain
> > >   UPN suffixes: alt.alt, alt.upn.suffix
> > >
> > > SSSD 1.14 and above on the IPA client should enable enterprise principal
> > > support automatically if UPN suffixes are found on the server but
> > according to
> > >
> > > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true]
> > enterprise principal [false] offline [false] UPN [rajat.gu...@mydomain.com
> > ]
> > >
> > > it is not. If the UPN suffixes are not know on the server, calling 'ipa
> > > trust-fetch-domain

Re: [Freeipa-users] minimise impact compromised host

[Sumit Bose]

On Wed, Nov 16, 2016 at 02:41:34PM +0100, Martin Babinsky wrote:
> On 11/16/2016 02:33 PM, Petr Spacek wrote:
> > On 16.11.2016 14:01, Stijn De Weirdt wrote:
> > > hi all,
> > > 
> > > we are looking how to configure whatever relevant policy to minimise the
> > > impact of compromised IPA hosts (ie servers with a valid host keytab).
> > > 
> > > in particular, it looks like it possible to retrieve any user token once
> > > you have access to a valid host keytab.
> > > 
> > > we're aware that the default IPA policies are wide open, but we are
> > > looking how to limit this. for us, there's no need that a hostkeytab can
> > > retrieve tokens for anything except the services on that host.
> > 
> > What "token" do you have in mind?
> > 
> We discussed this in another thread.
> 
> In the case that the host is compromised/stolen/hijacked, you can
> host-disable it to invalidate the keytab stored there but this does not
> prevent anyone logged on that host to bruteforce/DOS user accounts by trying
> to guess their Kerberos keys by repeated kinit.

But the password policy should at least mitigate this by blocking the
account for some time after a number of wrong password are used.

bye,
Sumit

> 
> -- 
> Martin^3 Babinsky
> 
> -- 
> 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] pam_winbind(sshd:auth): pam_get_item returned a password

[Sumit Bose]

On Wed, Nov 16, 2016 at 01:01:59PM +0100, Sumit Bose wrote:
> On Wed, Nov 16, 2016 at 12:49:59PM +0100, rajat gupta wrote:
> > I am using FreeIPA  version 4.4.0 Active Directory trust setup. And on
> > Active Directory side I am using UPN suffix.
> > Following are my domain setup.
> > 
> > AD DOMANIN :- corp.addomain.com
> > UPN suffix :- usern...@mydomain.com
> > IPA DOMAIN :- ipa.ipadomain.local
> > IPA server hostname:- ilt-gif-ipa01.ipa.ipadomain.local
> 
> When you call 'ipa trust-find' on the IPA server do you see the
> mydomain.com UPN suffix listed, like e.g.:
> 
> # ipa trust-find
> ---
> 1 trust matched
> ---
>   Realm-Name: ad.devel
>   Domain NetBIOS name: AD
>   Domain Security Identifier: S-1-5-21-3692237560-1981608775-3610128199
>   Trust type: Active Directory domain
>   UPN suffixes: alt.alt, alt.upn.suffix
> 
> SSSD 1.14 and above on the IPA client should enable enterprise principal
> support automatically if UPN suffixes are found on the server but according 
> to 
> 
> (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] 
> enterprise principal [false] offline [false] UPN [rajat.gu...@mydomain.com]
> 
> it is not. If the UPN suffixes are not know on the server, calling 'ipa
> trust-fetch-domains' might help to get them. If there are still no UPN 
> suffixes
> available on the server you can switch on enterprise principal on the client
> manually by adding  'krb5_use_enterprise_principal = True' in the [domain/...]
> section of sssd.conf. You have to set it manually as well if you are using
> older versions of SSSD.
> 
> HTH
> 
> bye,
> Sumit
> 
> > 
> > 
> > I am able to login with AD user on IPA server. But on IPA clinet i am not
> > able to login i am getting the login message "Access denied". I have
> > enabled the debug_level on sssd.conf on ipa clinet.
> > 
> > below are some logs..
> > 
> > /var/log/secure
> > 
> > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): authentication
> > failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=rg1989
> > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): received for
> > user e600336: 6 (Permission denied)
> > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): getting
> > password (0x0010)

By the way, why do you have pam_winbind in the PAM configuration?

bye,
Sumit

> > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth):
> > pam_get_item returned a password
> > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): internal
> > module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'rg1989')
> > Nov 16 09:00:52 ipa-clinet1 sshd[3752]: Failed password for e600336 from
> > x.x.x.x. port 48842 ssh2
> > 
> > 
> > 
> > krb5_child.log
> > 
> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836 [k5c_send_data]
> > (0x4000): Response sent.
> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836 [main] (0x0400):
> > krb5_child completed successfully
> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [main] (0x0400):
> > krb5_child started.
> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [unpack_buffer]
> > (0x1000): total buffer size: [159]
> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [unpack_buffer]
> > (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true]
> > enterprise principal [false] offline [false] UPN [rajat.gu...@mydomain.com]
> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [unpack_buffer]
> > (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname:
> > [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab]
> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [switch_creds]
> > (0x0200): Switch user to [1007656917][1007656917].
> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837
> > [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired.
> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [switch_creds]
> > (0x0200): Switch user to [0][0].
> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837
> > [k5c_check_old_ccache] (0x4000): Ccache_file is
> > [KEYRING:persistent:1007656917] and is not active and TGT is  valid.
> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837
> > [k5c_precreate_ccache] (0x4000): Recreating ccache
> > (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [k5c_setup_fast]
> > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to
> > [host/ipa-clinet1.ipa.ipadomain.local@IPA.IPADOM

Re: [Freeipa-users] pam_winbind(sshd:auth): pam_get_item returned a password

[Sumit Bose]

On Wed, Nov 16, 2016 at 12:49:59PM +0100, rajat gupta wrote:
> I am using FreeIPA  version 4.4.0 Active Directory trust setup. And on
> Active Directory side I am using UPN suffix.
> Following are my domain setup.
> 
> AD DOMANIN :- corp.addomain.com
> UPN suffix :- usern...@mydomain.com
> IPA DOMAIN :- ipa.ipadomain.local
> IPA server hostname:- ilt-gif-ipa01.ipa.ipadomain.local

When you call 'ipa trust-find' on the IPA server do you see the
mydomain.com UPN suffix listed, like e.g.:

# ipa trust-find
---
1 trust matched
---
  Realm-Name: ad.devel
  Domain NetBIOS name: AD
  Domain Security Identifier: S-1-5-21-3692237560-1981608775-3610128199
  Trust type: Active Directory domain
  UPN suffixes: alt.alt, alt.upn.suffix

SSSD 1.14 and above on the IPA client should enable enterprise principal
support automatically if UPN suffixes are found on the server but according to 

(0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true] 
enterprise principal [false] offline [false] UPN [rajat.gu...@mydomain.com]

it is not. If the UPN suffixes are not know on the server, calling 'ipa
trust-fetch-domains' might help to get them. If there are still no UPN suffixes
available on the server you can switch on enterprise principal on the client
manually by adding  'krb5_use_enterprise_principal = True' in the [domain/...]
section of sssd.conf. You have to set it manually as well if you are using
older versions of SSSD.

HTH

bye,
Sumit

> 
> 
> I am able to login with AD user on IPA server. But on IPA clinet i am not
> able to login i am getting the login message "Access denied". I have
> enabled the debug_level on sssd.conf on ipa clinet.
> 
> below are some logs..
> 
> /var/log/secure
> 
> Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): authentication
> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=x.x.x.x user=rg1989
> Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_sss(sshd:auth): received for
> user e600336: 6 (Permission denied)
> Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): getting
> password (0x0010)
> Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth):
> pam_get_item returned a password
> Nov 16 09:00:52 ipa-clinet1 sshd[3752]: pam_winbind(sshd:auth): internal
> module error (retval = PAM_AUTHINFO_UNAVAIL(9), user = 'rg1989')
> Nov 16 09:00:52 ipa-clinet1 sshd[3752]: Failed password for e600336 from
> x.x.x.x. port 48842 ssh2
> 
> 
> 
> krb5_child.log
> 
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836 [k5c_send_data]
> (0x4000): Response sent.
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4836 [main] (0x0400):
> krb5_child completed successfully
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [main] (0x0400):
> krb5_child started.
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [unpack_buffer]
> (0x1000): total buffer size: [159]
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [unpack_buffer]
> (0x0100): cmd [241] uid [1007656917] gid [1007656917] validate [true]
> enterprise principal [false] offline [false] UPN [rajat.gu...@mydomain.com]
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [unpack_buffer]
> (0x0100): ccname: [KEYRING:persistent:1007656917] old_ccname:
> [KEYRING:persistent:1007656917] keytab: [/etc/krb5.keytab]
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [switch_creds]
> (0x0200): Switch user to [1007656917][1007656917].
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837
> [sss_krb5_cc_verify_ccache] (0x2000): TGT not found or expired.
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [switch_creds]
> (0x0200): Switch user to [0][0].
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837
> [k5c_check_old_ccache] (0x4000): Ccache_file is
> [KEYRING:persistent:1007656917] and is not active and TGT is  valid.
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837
> [k5c_precreate_ccache] (0x4000): Recreating ccache
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [k5c_setup_fast]
> (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to
> [host/ipa-clinet1.ipa.ipadomain.local@IPA.IPADOMAIN.LOCAL]
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837
> [find_principal_in_keytab] (0x4000): Trying to find principal
> host/ipa-clinet1.ipa.ipadomain.local@IPA.IPADOMAIN.LOCAL in keytab.
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [match_principal]
> (0x1000): Principal matched to the sample
> (host/ipa-clinet1.ipa.ipadomain.local@IPA.IPADOMAIN.LOCAL).
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [check_fast_ccache]
> (0x0200): FAST TGT is still valid.
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [become_user]
> (0x0200): Trying to become user [1007656917][1007656917].
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [main] (0x2000):
> Running as [1007656917][1007656917].
> (Wed Nov 16 09:09:24 2016) [[sssd[krb5_child[4837 [k5c_setup] (0x2000):
> Running as 

Re: [Freeipa-users] sssd failed with 'ldap_sasl_bind failed(-2)[Localerror]'

[Sumit Bose]

On Thu, Nov 10, 2016 at 06:48:54PM +0800, Matrix wrote:
> Hi, Sumit
> 
> Thanks for your reply
> 
> I have tried. still failed

Do you see any related messages on the LDAP server side?

bye,
Sumit

> 
> # cat /etc/openldap/ldap.conf  | grep -v ^#
> 
> URI ldap://ipaslave.stg.example.net
> BASE dc=example,dc=net
> TLS_CACERT /etc/ipa/ca.crt
> SASL_MECH GSSAPI
> TLS_REQCERT allow
> SASL_NOCANON on
> 
> 
> # cat /etc/krb5.conf| grep rdns
>   rdns = false
> 
> Matrix
> 
> -- Original --
> From:  "Sumit Bose";<sb...@redhat.com>;
> Date:  Thu, Nov 10, 2016 06:32 PM
> To:  "freeipa-users"<freeipa-users@redhat.com>; 
> 
> Subject:  Re: [Freeipa-users] sssd failed with 'ldap_sasl_bind 
> failed(-2)[Localerror]'
> 
> 
> 
> On Thu, Nov 10, 2016 at 05:22:26PM +0800, Matrix wrote:
> > debug steps have been tried: 
> > 
> > 1 kinit is workable: 
> > # /usr/kerberos/bin/kinit -k host/client02.stg.example@example.net
> > 
> > # /usr/kerberos/bin/klist
> > Ticket cache: FILE:/tmp/krb5cc_0
> > Default principal: host/client02.stg.example@example.net
> > 
> > Valid starting ExpiresService principal
> > 11/10/16 09:18:00  11/11/16 09:17:35  krbtgt/example@example.net
> > 
> > Kerberos 4 ticket cache: /tmp/tkt0
> > klist: You have no tickets cached
> > 
> > 2 ldapwhoami with krb auth failed. 
> > 
> > # ldapwhoami -Y GSSAPI -h ipaslave.stg.example.net
> > SASL/GSSAPI authentication started
> > ldap_sasl_interactive_bind_s: Local error (-2)
> > additional info: SASL(-1): generic failure: GSSAPI Error: 
> > Unspecified GSS failure.  Minor code may provide more information (Mutual 
> > authentication failed)
> > 
> 
> Have you made sure that canonicalizing is disabled, i.e.
> /etc/krb5.conf: 
> [libdefaults]
>  ...
>  rdns = false
>  ...
> 
> /etc/openldap/ldap.conf
> ...
> SASL_NOCANONon
> ...
> 
> HTH
> 
> bye,
> Sumit
> 
> > 
> > Matrix
> > 
> > -- Original --
> > From:  "Matrix";<matrix...@qq.com>;
> > Date:  Thu, Nov 10, 2016 02:11 PM
> > To:  "freeipa-users"<freeipa-users@redhat.com>; 
> > 
> > Subject:  [Freeipa-users] sssd failed with 'ldap_sasl_bind failed 
> > (-2)[Localerror]'
> > 
> > 
> > 
> > Hi, 
> > 
> > I have installed sssd in a RHEL5 client. 
> > 
> > ipa-client/sssd version:
> > ipa-client-2.1.3-7.el5
> > sssd-client-1.5.1-71.el5
> > sssd-1.5.1-71.el5
> > 
> > sssd failed to get ipa user info with 'ldap_sasl_bind failed (-2)[Local 
> > error]'. 
> > 
> > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] 
> > (4): Executing sasl bind mech: GSSAPI, user: host/client02.stg.example.net
> > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] 
> > (1): ldap_sasl_bind failed (-2)[Local error]
> > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] 
> > (7): Waiting for child [7].
> > (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] 
> > (4): child [7] finished successfully.
> > 
> > I have tried to google to find root cause. some link explained it should be 
> > something wrong with dns. I have double confirmed it. 
> > 
> > # nslookup client02.stg.example.net
> > Server: 10.2.1.21
> > Address:10.2.1.21#53
> > 
> > Name:   client02.stg.example.net
> > Address: 10.2.3.32
> > 
> > 
> > # nslookup 10.2.3.32
> > Server: 10.2.1.21
> > Address:10.2.1.21#53
> > 
> > 32.3.2.10.in-addr.arpa  name = client02.stg.example.net.
> > 
> > 
> > # nslookup ipaslave.stg.example.net
> > Server: 10.2.1.21
> > Address:10.2.1.21#53
> > 
> > Name:   ipaslave.stg.example.net
> > Address: 10.2.1.250
> > 
> > # nslookup 10.2.1.250
> > Server: 10.2.1.21
> > Address:10.2.1.21#53
> > 
> > 250.1.2.10.in-addr.arpa name = ipaslave.stg.example.net.
> > 
> > Any hints or troubleshooting ideas would be appreciated. 
> > 
> > Matrix
> 
> > -- 
> > 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

-- 
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 failed with 'ldap_sasl_bind failed (-2)[Localerror]'

[Sumit Bose]

On Thu, Nov 10, 2016 at 05:22:26PM +0800, Matrix wrote:
> debug steps have been tried: 
> 
> 1 kinit is workable: 
> # /usr/kerberos/bin/kinit -k host/client02.stg.example@example.net
> 
> # /usr/kerberos/bin/klist
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: host/client02.stg.example@example.net
> 
> Valid starting ExpiresService principal
> 11/10/16 09:18:00  11/11/16 09:17:35  krbtgt/example@example.net
> 
> Kerberos 4 ticket cache: /tmp/tkt0
> klist: You have no tickets cached
> 
> 2 ldapwhoami with krb auth failed. 
> 
> # ldapwhoami -Y GSSAPI -h ipaslave.stg.example.net
> SASL/GSSAPI authentication started
> ldap_sasl_interactive_bind_s: Local error (-2)
> additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified 
> GSS failure.  Minor code may provide more information (Mutual authentication 
> failed)
> 

Have you made sure that canonicalizing is disabled, i.e.
/etc/krb5.conf: 
[libdefaults]
 ...
 rdns = false
 ...

/etc/openldap/ldap.conf
...
SASL_NOCANONon
...

HTH

bye,
Sumit

> 
> Matrix
> 
> -- Original --
> From:  "Matrix";;
> Date:  Thu, Nov 10, 2016 02:11 PM
> To:  "freeipa-users"; 
> 
> Subject:  [Freeipa-users] sssd failed with 'ldap_sasl_bind failed 
> (-2)[Localerror]'
> 
> 
> 
> Hi, 
> 
> I have installed sssd in a RHEL5 client. 
> 
> ipa-client/sssd version:
> ipa-client-2.1.3-7.el5
> sssd-client-1.5.1-71.el5
> sssd-1.5.1-71.el5
> 
> sssd failed to get ipa user info with 'ldap_sasl_bind failed (-2)[Local 
> error]'. 
> 
> (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (4): 
> Executing sasl bind mech: GSSAPI, user: host/client02.stg.example.net
> (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [sasl_bind_send] (1): 
> ldap_sasl_bind failed (-2)[Local error]
> (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] 
> (7): Waiting for child [7].
> (Thu Nov 10 05:52:45 2016) [sssd[be[stg.example.net]]] [child_sig_handler] 
> (4): child [7] finished successfully.
> 
> I have tried to google to find root cause. some link explained it should be 
> something wrong with dns. I have double confirmed it. 
> 
> # nslookup client02.stg.example.net
> Server: 10.2.1.21
> Address:10.2.1.21#53
> 
> Name:   client02.stg.example.net
> Address: 10.2.3.32
> 
> 
> # nslookup 10.2.3.32
> Server: 10.2.1.21
> Address:10.2.1.21#53
> 
> 32.3.2.10.in-addr.arpa  name = client02.stg.example.net.
> 
> 
> # nslookup ipaslave.stg.example.net
> Server: 10.2.1.21
> Address:10.2.1.21#53
> 
> Name:   ipaslave.stg.example.net
> Address: 10.2.1.250
> 
> # nslookup 10.2.1.250
> Server: 10.2.1.21
> Address:10.2.1.21#53
> 
> 250.1.2.10.in-addr.arpa name = ipaslave.stg.example.net.
> 
> Any hints or troubleshooting ideas would be appreciated. 
> 
> Matrix

> -- 
> 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 - AD trust - SSH Public Keys

[Sumit Bose]

On Fri, Nov 04, 2016 at 01:41:40PM +0200, Taras Drach wrote:
> Hello Sumit,
> I’ve tried to use this attr, but still no success
> 
> Also I found the solutions where sss_ssh_authorizedkeys replaced with custom 
> scripts for queuing ldap and get necessary attribute
> I think there is hardcoded “sshPublicKey" in sss_ssh_authorizedkeys. 

yes, sshPublicKey is hardcoded but originalADsshPublicKey should be
handled as well. I just found that there is a bug which prevents the ssh
responder to handle it as expected.

In general the attribute names in SSSD's cache are hardcoded. What is
configurable is which server side LDAP attributed is stored in a
specific cache attribute (all the ldap_user_* and ldap_group_*
attributes can be used for this.

ldap_user_extra_attrs is special to allow to stored arbitrary attributes
in the cache. But since the hardcoded cache attributes typically have
special use-cases they cannot be overridden, this is why you have seen
the error message with sshPublicKey. originalADsshPublicKey has some
special instal use-case as well, but currently it is not in the list of
attributes which is checked. Nevertheless there is the bug I mentioned
earlier which make the lookup fail as well.

The intended way to solve all this is to use "ldap_user_ssh_public_key =
altSecurityIdentities" which I expect to work in the case where the
client is joined directly to an AD domain.  With IPA and trust this is
unfortunately a bit different. The ldap_user_ssh_public_key will only
change the attribute name for the IPA domain but not for the trusted AD
domain because options are not inherited by default. Additionally
changing the attribute name for the IPA domain will prevent SSSD from
reading the SSH keys stored in the IPA server. The proper solution would
be domain specific configuration options which is tracked by
https://fedorahosted.org/sssd/ticket/2599 .

Nevertheless I try to fix the bug I mentioned earlier and will prepare a
test-build with a fix at the beginning of the next week.

HTH

bye,
Sumit


> Is there any other way to create some kind of mapping in IPA for this 
> attribute? 
> I see that AD attribute requested and printed its content in the log, but 
> still sss_ssh_authorizedkeys did not print this key to stdout
> 
> Full trace of 
> sss_ssh_authorizedkeys -d test.loc rr
> ==
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_get_account_info] 
> (0x0200): Got request for [0x1][1][name=rr]
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [be_req_set_domain] 
> (0x0400): Changing request domain from [ipa.test.loc] to [test.loc]
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_step] 
> (0x4000): reusing cached connection
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_step] 
> (0x4000): reusing cached connection
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] 
> [ipa_get_ad_override_connect_done] (0x4000): Searching for overrides in view 
> [Default Trust View] with filter [(&(objectClass=ipaUserOverride)(uid=rr))].
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_print_server] 
> (0x2000): Searching 10.100.0.4
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] 
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with 
> [(&(objectClass=ipaUserOverride)(uid=rr))][cn=Default Trust 
> View,cn=views,cn=accounts,dc=ipa,dc=test,dc=loc].
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] 
> [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 6
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_add] (0x2000): 
> New operation 6 timeout 60
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_result] 
> (0x2000): Trace: sh[0x7f0de13ebfe0], connected[1], ops[0x7f0de1415190], 
> ldap[0x7f0de13e8be0]
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_process_message] 
> (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] 
> [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg 
> set
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_op_destructor] 
> (0x2000): Operation 6 finished
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] 
> [ipa_get_ad_override_done] (0x4000): No override found with filter 
> [(&(objectClass=ipaUserOverride)(uid=rr))].
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_destroy] 
> (0x4000): releasing operation connection
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] 
> [ipa_srv_ad_acct_lookup_step] (0x0400): Looking up AD account
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [sdap_id_op_connect_step] 
> (0x4000): beginning to connect
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [fo_resolve_service_send] 
> (0x0100): Trying to resolve service 'test.loc'
> (Fri Nov  4 11:22:21 2016) [sssd[be[ipa.test.loc]]] [get_server_status] 
> (0x1000): Status of server 'dc01.test.loc' is 'working'
> (Fri Nov  4 

Re: [Freeipa-users] FreeIPA - AD trust - SSH Public Keys

[Sumit Bose]

On Thu, Nov 03, 2016 at 05:23:06PM +0200, Taras Drach wrote:
> Thank for reply,
> 
> Unfortunately sssd won’t start with this configuration
> 
> Here is part of log
> 
> (Thu Nov  3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sdap_extend_map] 
> (0x0200): 1 extra attributes
> (Thu Nov  3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sdap_extend_map] 
> (0x0010): Attribute sshPublicKey (altSecurityIdentities in LDAP) is already 
> used by SSSD, please choose a different cache name

Can you check if 

ldap_user_extra_attrs = originalADsshPublicKey:altSecurityIdentities

works any better?

bye,
Sumit

> (Thu Nov  3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [load_backend_module] 
> (0x0010): Error (1432158241) in module (ipa) initialization 
> (sssm_ipa_id_init)!
> (Thu Nov  3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [be_process_init] 
> (0x0010): fatal error initializing data providers
> (Thu Nov  3 15:16:40 2016) [sssd[be[ipa.test.loc]]] [sbus_remove_watch] 
> (0x2000): 0x7f8183df2640/0x7f8183df2420
> 
> Config changes:
> 
>ldap_user_extra_attrs = sshPublicKey:altSecurityIdentities
> #   ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
>ldap_user_ssh_public_key = altSecurityIdentities
>ldap_id_mapping = False
> 
> > On Nov 3, 2016, at 5:05 PM, Sumit Bose <sb...@redhat.com> wrote:
> > 
> >  sshPublicKey:
> 


-- 
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 - AD trust - SSH Public Keys

[Sumit Bose]

On Thu, Nov 03, 2016 at 04:35:30PM +0200, Taras Drach wrote:
> Hello everyone!
> 
> I want to implement next scheme:
> 
> 1. Use AD as place for user management
> 2. Store ssh public keys in AD
> 3. Use FreeIPA as sudo/hbac provider for AD groups for authentication and 
> authorisation on the linux hosts
> 4. Use trusts roadmap (do not want to synchronise)
> 
> My configuration is:
> AD domain - test.loc - windows server 2012 r2
> IPA domain - ipa.test.loc - ipa-server 4.2.0 on centos 7 (ipa-server.x86_64   
>  4.2.0-15.0.1.el7.centos.19  @updates)
> 
> At this moment everything fine except SSH public keys.
> 
> I tried to use override and it works fine (I can login to linux host with AD 
> user with public key), but I have to create view in ipa for each user from 
> AD. It is not my goal and its also create inconveniences.
> 
> I found that there are several ways to achieve desired configuration:
> 1. Extend AD scheme with sshPublicKey attribute
> 2. Use altSecurityIdentities attribute from AD
> 
> At this moment I can obtain ssh public key from ipa  for user by
> sss_ssh_authorizedkeys -d ipa.test.loc user or
> sss_ssh_authorizedkeys user, because ipa.test.loc is default domain
> 
> But I can’t receive key for AD user using this command
> sss_ssh_authorizedkeys -d test.loc
> 
> At this moment I try to obtain key via altSecurityIdentities, and I see this 
> key in sssd debug log when I run sss_ssh_authorizedkeys, but I can not see 
> public key on stdout
> Here is the part if log
> -
...
> 
> 
> Here is my sssd.conf for ipa domain
> 
> domain/ipa.test.loc]
> debug_level = 0xfff0
> 
> cache_credentials = True
> krb5_store_password_if_offline = True
> ipa_domain = ipa.test.loc
> id_provider = ipa
> auth_provider = ipa
> access_provider = ipa
> ipa_hostname = ipa42.ipa.test.loc
> chpass_provider = ipa
> ipa_server = ipa42.ipa.test.loc
> ipa_server_mode = True
> ldap_tls_cacert = /etc/ipa/ca.crt
> create_homedir = True
> ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities

SSH public keys must must be stored with the attribute name 'sshPublicKey' in 
SSSD's cache, please try

ldap_user_extra_attrs = sshPublicKey:altSecurityIdentities

> ldap_user_ssh_public_key = altSecurityIdentities
> ldap_id_mapping = False
> 
> 
> 

HTH

bye,
Sumit

-- 
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] SSH as Root on CentOS 7 fails

[Sumit Bose]

On Mon, Oct 31, 2016 at 04:17:08PM -0400, Geordie Grindle wrote:
> 
> Hello,
> 
> I’m unable to ssh as ‘root’ onto any of my new CentOS 7 hosts. I’ve always 
> been able to do so on CentOS6.x
> 
> We normally have the file ‘/root/.k5login’ listing the designated system 
> admins’ principals. Once on a CentOS 7, an admin can ‘ksu’ and become root as 
> we expected.
> 
> We are using puppet and Foreman to build our hosts so they are in every way 
> we can think of, identical, except for the O/s version.
> 
> I’ve confirmed forward and reverse DNS and that the ‘kvno’ number matches 
> what’s reported by ‘klist -k’. 
> 
> I enabled "LogLevel DEBUG” in sshd_config and restarted sshd on a CentOS7 
> host: 
> 
> Oct 31 19:22:36 someserver sshd[12378]: debug1: userauth-request for user 
> testuser service ssh-connection method none [preauth]
> Oct 31 19:22:36 someserver sshd[12378]: debug1: attempt 0 failures 0 [preauth]
> Oct 31 19:22:36 someserver sshd[12378]: debug1: PAM: initializing for 
> "testuser"
> Oct 31 19:22:36 someserver sshd[12378]: debug1: PAM: setting PAM_RHOST to 
> "someserver.test.com"
> Oct 31 19:22:36 someserver sshd[12378]: debug1: PAM: setting PAM_TTY to "ssh"
> Oct 31 19:22:36 someserver sshd[12378]: debug1: userauth-request for user 
> testuser service ssh-connection method gssapi-with-mic [preauth]
> Oct 31 19:22:36 someserver sshd[12378]: debug1: attempt 1 failures 0 [preauth]
> Oct 31 19:22:36 someserver sshd[12378]: Postponed gssapi-with-mic for 
> testuser from 10.0.0.55 port 36383 ssh2 [preauth]
> Oct 31 19:22:36 someserver sshd[12378]: debug1: Received some client 
> credentials
> Oct 31 19:22:36 someserver sshd[12378]: Authorized to testuser, krb5 
> principal testu...@test.com (ssh_gssapi_krb5_cmdok)
> 
> 
> 
> Oct 31 19:35:42 someserver sshd[12409]: debug1: userauth-request for user 
> root service ssh-connection method none [preauth]
> Oct 31 19:35:42 someserver sshd[12409]: debug1: attempt 0 failures 0 [preauth]
> Oct 31 19:35:42 someserver sshd[12409]: debug1: PAM: initializing for "root"
> Oct 31 19:35:42 someserver sshd[12409]: debug1: PAM: setting PAM_RHOST to 
> "someserver.test.com"
> Oct 31 19:35:42 someserver sshd[12409]: debug1: PAM: setting PAM_TTY to "ssh"
> Oct 31 19:35:42 someserver sshd[12409]: debug1: userauth-request for user 
> root service ssh-connection method gssapi-with-mic [preauth]
> Oct 31 19:35:42 someserver sshd[12409]: debug1: attempt 1 failures 0 [preauth]
> Oct 31 19:35:42 someserver sshd[12409]: Postponed gssapi-with-mic for root 
> from 10.0.0.55 port 36384 ssh2 [preauth]
> Oct 31 19:35:42 someserver sshd[12409]: debug1: Received some client 
> credentials
> Oct 31 19:35:42 someserver sshd[12409]: Failed gssapi-with-mic for root from 
> 10.0.0.55 port 36384 ssh2
> ...
> Oct 31 19:35:42 someserver sshd[12577]: debug1: userauth-request for user 
> root service ssh-connection method gssapi-with-mic [preauth]
> Oct 31 19:35:42 someserver sshd[12577]: debug1: attempt 4 failures 1 [preauth]
> 
> Appreciate any thoughts or suggestions you have.

Which version of SSSD are you using. SSSD provides a localauth plugin to
make matching the Kerberos principal and the provided login name more
easy. It creates a configuration snippet for krb5.conf in
/var/lib/sss/pubconf/krb5.include.d/localauth_plugin and the content
should typically look like

[plugins]
 localauth = {
  module = sssd:/usr/lib/sssd/modules/sssd_krb5_localauth_plugin.so
 }


Some versions of SSSD added a 'enable_only = sssd' line which disables
the .k5login checks. If you have this line in the localauth_plugin file
I would recommend to check if a newer version of SSSD is available for
your platform which do not create the line. As an alternative you can
just remove the line from the file. But since SSSD will recreate the
file at startup you should make it immutable with chattr and the 'i'
option.

HTH

bye,
Sumit

> 
> Yours,
> Geordie Grindle
> 
> 
> -- 
> 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] cannot ssh in (sss_ssh_authorizedkeys returned status 1) ??

[Sumit Bose]

On Fri, Oct 21, 2016 at 01:55:19PM +0100, lejeczek wrote:
> hi all
> 
> I cannot ssh from a boxA (ipa-server-4.2.0-15.sl7_2.19.x86_64) to a boxB
> (ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64)
> I realize that to assume versions differences cause it is bit silly but
> nothing changed except update of boxB's IPA a day before the problem occur.
> Also, there is a boxC (ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64) (so
> boxB == boxC IPA-wise) which does ssh in fine.
> Other way around, boxB to boxA ssh works.
> Logs are pretty quiet, I merely see:
> 
> error: AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys returned status
> 1
> 
> and that I'm not sure appears at the time of login attempt.
> I do:
> boxA$ ssh boxB
> Connection closed by UNKNOWN
> 
> ps. boxA is not banned nor block by any tcp/ip means.
> 
> many! thanks for any help

Which version of SSSD is running? Do you have user certificates stored
in IPA? In this case you might hit
https://bugzilla.redhat.com/show_bug.cgi?id=1372042
https://fedorahosted.org/sssd/ticket/2977

If there are no updates with a fix available you might want to set

ldap_user_certificate = noSuchSttribute

in the [domain/...] section of sssd.conf to tell SSSD to not read the
certificates from the server. As an alternative you can all CA
certificates needed to validate the user certificates properly to
/etc/pki/nssdb.

HTH

bye,
Sumit

> L.
> 
> -- 
> 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] Unable to resolve AD users from IPA

[Sumit Bose]

On Wed, Oct 19, 2016 at 12:08:01PM +0200, Jan Karásek wrote:
> Hi, 
> 
> thank you for help. 
> 
> This is my sssd.conf from server : 
> 
> [domain/vs.example.cz] 
> debug_level = 7 
> cache_credentials = True 
> krb5_store_password_if_offline = True 
> ipa_domain = vs.example.cz 
> id_provider = ipa 
> auth_provider = ipa 
> access_provider = ipa 
> ipa_hostname = tidmipa02.vs.example.cz 
> chpass_provider = ipa 
> ipa_server = tidmipa02.vs.example.cz 
> ipa_server_mode = True 
> ldap_tls_cacert = /etc/ipa/ca.crt 
> [sssd] 
> services = nss, sudo, pam, ssh 
> config_file_version = 2 
> 
> domains = vs.example.cz 
> [nss] 
> debug_level = 7 
> memcache_timeout = 600 
> homedir_substring = /home 
> 
> [pam] 
> debug_level = 7 
> [sudo] 
> debug_level = 7 
> [autofs] 
> debug_level = 7 
> [ssh] 
> debug_level = 7 
> [pac] 
> debug_level = 7 
> [ifp] 
> debug_level = 7 
> 
> 
> I can resolve all groups from client : 
> 
> SERVER: id tst99...@cen.example.cz 
> uid=20019(tst99...@cen.example.cz) gid=5001(csunix) 
> groups=5001(csunix),93008(final_test_group) 
> 
> CLIENT: 
> getent group 5001 
> csunix:x:5001: 
> 
> getent group 93008 
> final_test_group:*:93008: 
> 
> getent group final_test_gr...@vs.example.cz 
> final_test_group:*:93008: 
> 
> getent group csu...@cen.example.cz 
> No reply - can't resolve that group from client. 
> 
> 
...

> 
> Also I find out that in AD there are multiple objects with gidNumber=5001 

This might be the issue each gidNumber (and each uidNumber as well)
should be unique in the whole environment. Please check with the AD
administrators why it was done this way and if it can be changed.

HTH

bye,
Sumit

> 
> ldapsearch  
> (&(gidNumber=5001)(objectClass=group)(sAMAccountName=*)(&(gidNumber=*)(!(gidNumber=0
>  > /tmp/csunix_dump 
> cat /tmp/csunix_dump 
> dn: CN=csunix_0,OU=POSIXGroups,OU=Groups,DC=cen,DC=example,DC=cz 
> objectClass: top 
> objectClass: posixGroup 
> objectClass: group 
> cn: csunix_0 
> ... 
> gidNumber: 5001 
> 
> dn: CN=csunix_1,OU=POSIXGroups,OU=Groups,DC=cen,DC=example,DC=cz 
> objectClass: top 
> objectClass: posixGroup 
> objectClass: group 
> cn: csunix_1 
>  
> gidNumber: 5001 
> 
> dn: CN=csunix_2,OU=POSIXGroups,OU=Groups,DC=cen,DC=example,DC=cz 
> objectClass: top 
> objectClass: posixGroup 
> objectClass: group 
> cn: csunix_2 
> ... 
> gidNumber: 5001 
> 
> dn: CN=csunix_3,OU=POSIXGroups,OU=Groups,DC=cen,DC=example,DC=cz 
> objectClass: top 
> objectClass: posixGroup 
> objectClass: group 
> cn: csunix_3 
> ... 
> gidNumber: 5001 
> 
> dn: CN=csunix_4,OU=POSIXGroups,OU=Groups,DC=cen,DC=example,DC=cz 
> objectClass: top 
> objectClass: posixGroup 
> objectClass: group 
> cn: csunix_4 
> ... 
> gidNumber: 5001 
> 
> dn: CN=csunix_5,OU=POSIXGroups,OU=Groups,DC=cen,DC=example,DC=cz 
> objectClass: top 
> objectClass: posixGroup 
> objectClass: group 
> cn: csunix_5 
> ... 
> gidNumber: 5001 
> 
> dn: CN=csunix,OU=POSIXGroups,OU=Groups,DC=cen,DC=example,DC=cz 
> objectClass: top 
> objectClass: posixGroup 
> objectClass: group 
> cn: csunix 
> ... 
> gidNumber: 5001 
> 

-- 
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] Unable to resolve AD users from IPA client

[Sumit Bose]

On Mon, Oct 17, 2016 at 01:27:40PM +0200, Jan Karásek wrote:
> Hi, 
> please can you help me with troubleshooting IPA clients in IPA - AD trust 
> scenario ? We have two IPA servers and couple of clients running on RHEl 6 
> and 7. IPA is running on RHEL 7.2. 
> AD servers are in domains example.cz, cen.example.cz. Test users sits in 
> cen.example.cz. IPA is subdomain of AD - vs.example.cz. 
> Trust is set as one-way trust. User's POSIX attributes are stored in AD. 
> 
> ipa idrange-find 
>  
> 3 ranges matched 
>  
> Range name: CEN.EXAMPLE.CZ 
> First Posix ID of the range: 9880 
> Number of IDs in the range: 20 
> Domain SID of the trusted domain: S-1-5-21-527237240-1482476501-682003330 
> Range type: Active Directory trust range with POSIX attributes 
> 
> Range name: EXAMPLE.CZ_id_range 
> First Posix ID of the range: 6880 
> Number of IDs in the range: 20 
> Domain SID of the trusted domain: S-1-5-21-73586283-1958367476-682003330 
> Range type: Active Directory trust range with POSIX attributes 
> 
> Range name: VS.EXAMPLE.CZ_id_range 
> First Posix ID of the range: 93000 
> Number of IDs in the range: 20 
> First RID of the corresponding RID range: 1000 
> First RID of the secondary RID range: 1 
> Range type: local domain range 
>  
> Number of entries returned 3 
>  
> 
> I have no problem to resolve AD users from both IPA server: 
> 
> IPA Server: 
> root#:id tst99...@cen.example.cz 
> uid=20019(tst99...@cen.example.cz) gid=5001(csunix) 
> groups=5001(csunix),93008(final_test_group) - this is correct 

Can you send your sssd.conf from the server? I wonder why the AD groups
are returned with a short name 'csunix' while the user is returned with
the full name (tst99...@cen.example.cz).

bye,
Sumit

> 
> but from IPA client: 
> root#:id tst99...@cen.example.cz 
> id: tst99...@cen.example.cz: no such user 
> 
> ==> sssd_vs.example.cz.log <== 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [be_get_account_info] 
> (0x0200): Got request for [0x1001][1][name=tst99654] 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [be_req_set_domain] 
> (0x0400): Changing request domain from [vs.example.cz] to [cen.example.cz] 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with 
> [(&(objectClass=ipaUserOverride)(uid=tst99654))][cn=Default Trust 
> View,cn=views,cn=accounts,dc=vs,dc=example,dc=cz]. 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg 
> set 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [ipa_s2n_exop_send] 
> (0x0400): Executing extended operation 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [ipa_s2n_exop_done] 
> (0x0400): ldap_extended_operation result: Success(0), (null). 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [sysdb_search_by_name] 
> (0x0400): No such entry 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [sysdb_search_by_name] 
> (0x0400): No such entry 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [ipa_s2n_exop_send] 
> (0x0400): Executing extended operation 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [ipa_s2n_exop_done] 
> (0x0040): ldap_extended_operation result: No such object(32), (null). 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] 
> [ipa_s2n_get_fqlist_next] (0x0040): s2n exop request failed. 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] 
> [ipa_s2n_get_fqlist_done] (0x0040): s2n get_fqlist request failed. 
> (Mon Oct 17 12:24:29 2016) [sssd[be[vs.example.cz]]] [acctinfo_callback] 
> (0x0100): Request processed. Returned 0,0,Success (Success) 
> 
> All IPA clients have the same result - No such user. On the other hand 
> kerberos works fine - I can do kinit with AD users both on IPA servers and 
> clients. All IPA clients use the same DNS server as IPA servers. 
> 
> 
> On IPA server, I can see that it is able to find test user in AD. Log is 
> captured during IPA client request for id: 
> 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with 
> [(&(sAMAccountName=tst99654)(objectclass=user)(sAMAccountName=*)(&(uidNumber=*)(!(uidNumber=0][dc=cen,dc=example,dc=cz].
>  
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sAMAccountName] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [unixUserPassword] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] 
> [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uidNumber] 
> (Mon Oct 17 12:26:05 2016) [sssd[be[vs.example.cz]]] 

Re: [Freeipa-users] diskless workstations in an IPA domain

[Sumit Bose]

On Fri, Oct 14, 2016 at 12:41:23AM +0200, Jacquelin Charbonnel wrote:
>   Thank you for this information. Yes, /tmp is writable.
> 
>   My problem is : access are sometimes definitively refused for random 
> user
> who wants to log in diskless workstations.
>   But if this banned user tries to connect to the single machine which 
> mounts
> the fs in rw mode, it's work, and this solve immediately its problem on all
> the other stateless machines !? Strange...

Maybe it is the selinux_provider, iirc at least in older version it used
to write some data somewhere below /etc/selinux/. You can easily test
this by setting 'selinux_provider = none' in the domain section in
ssd.conf.

HTH

bye,
Sumit

> 
> Le 13/10/2016 à 20:33, Jakub Hrozek a écrit :
> > On Thu, Oct 13, 2016 at 05:45:32PM +0200, Jacquelin Charbonnel wrote:
> > > Hi everybody,
> > > 
> > >   What is the best practice to enroll diskless Fedora24 workstations 
> > > (under
> > > stateless Linux) into a IPA domain ?
> > >   Each diskless workstation mounts its filesystem in RO mode from a single
> > > NFS share, with some specific directories (like /var/lib/sss) mapped RW in
> > > RAM.
> > 
> > I can't speak for other components, but /var/lib/sss/ is the only
> > directory sssd writes to (except tmpfiles, but I guess /tmp would also
> > be a writable fs?)
> > 
> 
> -- 
> Jacquelin Charbonnel - (+33)2 4173 5397
> CNRS Mathrice/LAREMA - Campus universitaire d'Angers
> 
> -- 
> 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] Error looking up public keys

[Sumit Bose]

On Thu, Oct 06, 2016 at 09:55:30PM +0100, Alessandro De Maria wrote:
> The workaround worked thank you!

Great, glad I could help.

bye,
Sumit

> 
> On 6 Oct 2016 5:09 pm, "Sumit Bose" <sb...@redhat.com> wrote:
> 
> > On Thu, Oct 06, 2016 at 03:48:10PM +0100, Alessandro De Maria wrote:
> > > Hello,
> > >
> > > We are moving some of our servers to use 16.04 and for all new installs I
> > > have noticed that I am unable to fetch the ssh_authorized keys from the
> > > server.
> > >
> > > /usr/bin/sss_ssh_authorizedkeys --debug 10 -d prod.zzz.com ademaria
> > > (Thu Oct  6 11:29:59:823635 2016) [/usr/bin/sss_ssh_authorizedkeys]
> > [main]
> > > (0x0020): sss_ssh_get_ent() failed (14): Bad address
> > > Error looking up public keys
> > >
> > > This only happens on Ubuntu 16.04. We have a number of 12.04 that work
> > > perfectly.
> > >
> > > The configuration seems ok or at least matches the one on 12.04.
> > > I increased the debug level on sssd and sss_ssh and this is the output I
> > get
> >
> > ...
> >
> > > (Thu Oct  6 15:42:01 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0040):
> > > NSS_InitContext failed [-8015].
> > > (Thu Oct  6 15:42:01 2016) [sssd[ssh]] [decode_and_add_base64_data]
> > > (0x0040): cert_to_ssh_key failed.
> > > (Thu Oct  6 15:42:01 2016) [sssd[ssh]] [ssh_cmd_build_reply] (0x0040):
> > > decode_and_add_base64_data failed.
> > > (Thu Oct  6 15:42:01 2016) [sssd[ssh]] [ssh_cmd_done] (0x0020): Fatal
> > > error, killing connection!
> >
> > ...
> >
> > Newer version of SSSD can derive ssh-keys from valid X.509 certificates
> > stored in the LDAP entry of the user. Unfortunately it looks like in
> > your build of SSSD needs a fix for
> > https://fedorahosted.org/sssd/ticket/2977. Please open a ticket for your
> > distribution to include the patch for this issue which is linked at the
> > end of the ticket.
> >
> > As a workaround you can set 'ldap_user_certificate = noSuchAttribute' in
> > the [domain/...] section of sssd.conf. This should prevent SSSD from
> > reading the certificate stored in the user entry. After changing
> > sssd.conf you should invalidate the cache by calling 'sss_cache -E' and
> > restart SSSD.
> >
> > HTH
> >
> > bye,
> > Sumit
> >
> > >
> > > Could you help me understand what is the issue with it?
> > >
> > > Regards
> > > Alessandro
> > >
> > > --
> > > Alessandro De Maria
> > > alessandro.dema...@gmail.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
> >

-- 
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] Error looking up public keys

[Sumit Bose]

On Thu, Oct 06, 2016 at 03:48:10PM +0100, Alessandro De Maria wrote:
> Hello,
> 
> We are moving some of our servers to use 16.04 and for all new installs I
> have noticed that I am unable to fetch the ssh_authorized keys from the
> server.
> 
> /usr/bin/sss_ssh_authorizedkeys --debug 10 -d prod.zzz.com ademaria
> (Thu Oct  6 11:29:59:823635 2016) [/usr/bin/sss_ssh_authorizedkeys] [main]
> (0x0020): sss_ssh_get_ent() failed (14): Bad address
> Error looking up public keys
> 
> This only happens on Ubuntu 16.04. We have a number of 12.04 that work
> perfectly.
> 
> The configuration seems ok or at least matches the one on 12.04.
> I increased the debug level on sssd and sss_ssh and this is the output I get

...

> (Thu Oct  6 15:42:01 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0040):
> NSS_InitContext failed [-8015].
> (Thu Oct  6 15:42:01 2016) [sssd[ssh]] [decode_and_add_base64_data]
> (0x0040): cert_to_ssh_key failed.
> (Thu Oct  6 15:42:01 2016) [sssd[ssh]] [ssh_cmd_build_reply] (0x0040):
> decode_and_add_base64_data failed.
> (Thu Oct  6 15:42:01 2016) [sssd[ssh]] [ssh_cmd_done] (0x0020): Fatal
> error, killing connection!

...

Newer version of SSSD can derive ssh-keys from valid X.509 certificates
stored in the LDAP entry of the user. Unfortunately it looks like in
your build of SSSD needs a fix for
https://fedorahosted.org/sssd/ticket/2977. Please open a ticket for your
distribution to include the patch for this issue which is linked at the
end of the ticket.

As a workaround you can set 'ldap_user_certificate = noSuchAttribute' in
the [domain/...] section of sssd.conf. This should prevent SSSD from
reading the certificate stored in the user entry. After changing
sssd.conf you should invalidate the cache by calling 'sss_cache -E' and
restart SSSD.

HTH

bye,
Sumit

> 
> Could you help me understand what is the issue with it?
> 
> Regards
> Alessandro
> 
> -- 
> Alessandro De Maria
> alessandro.dema...@gmail.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] SELinux errors with sssd-krb5-common-1.13.0-40.el7_2.12.x86_64

[Sumit Bose]

On Thu, Sep 29, 2016 at 12:07:13PM -0400, Prasun Gera wrote:
> I need to set SELinux to enforcing to get the relevant SSSD logs, right ?

yes, I think this would help to identify the operation which triggers
the AVC because it should fail.

bye,
Sumit

> 
> On Thu, Sep 29, 2016 at 3:42 AM, Sumit Bose <sb...@redhat.com> wrote:
> 
> > On Thu, Sep 29, 2016 at 12:47:34AM -0400, Prasun Gera wrote:
> > > I started seeing some selinux errors on one of my RHEL 7 clients recently
> > > (possibly after a recent yum update ?), which prevents users from logging
> > > in with passwords. I've put SELinux in permissive mode for now. Logs
> > follow
> >
> > This sounds like https://bugzilla.redhat.com/show_bug.cgi?id=1301686 .
> > Would you mind adding your findings and the SSSD logs as described in
> > https://bugzilla.redhat.com/show_bug.cgi?id=1301686#c2 to the bugzilla
> > ticket.
> >
> > Thank you.
> >
> > bye,
> > Sumit
> >
> > >
> > >
> > > SELinux is preventing /usr/libexec/sssd/krb5_child from read access on
> > the
> > > key Unknown.
> > >
> > > *  Plugin catchall (100. confidence) suggests
> > > **
> > >
> > > If you believe that krb5_child should be allowed read access on the
> > Unknown
> > > key by default.
> > > Then you should report this as a bug.
> > > You can generate a local policy module to allow this access.
> > > Do
> > > allow this access for now by executing:
> > > # grep krb5_child /var/log/audit/audit.log | audit2allow -M mypol
> > > # semodule -i mypol.pp
> > >
> > >
> > > Additional Information:
> > > Source Contextsystem_u:system_r:sssd_t:s0
> > > Target Contextsystem_u:system_r:unconfined_service_t:s0
> > > Target ObjectsUnknown [ key ]
> > > Sourcekrb5_child
> > > Source Path   /usr/libexec/sssd/krb5_child
> > > Port  
> > > Host  
> > > Source RPM Packages   sssd-krb5-common-1.13.0-40.el7_2.12.x86_64
> > > Target RPM Packages
> > > Policy RPMselinux-policy-3.13.1-60.el7_2.9.noarch
> > > Selinux Enabled   True
> > > Policy Type   targeted
> > > Enforcing ModePermissive
> > > Host Name example.com
> > > Platform  Linux example.com 4.4.19-1.el7.x86_64
> > >   #1 SMP Mon Aug 29 18:38:32 EDT 2016 x86_64
> > > x86_64
> > > Alert Count   38
> > > First Seen2016-09-28 18:37:43 EDT
> > > Last Seen 2016-09-28 22:08:41 EDT
> > > Local ID  aa5271fa-f708-46b0-a382-fb1f90ce8973
> > > Raw Audit Messages
> > > type=AVC msg=audit(1475114921.376:90787): avc:  denied  { read } for
> > >  pid=8272 comm="krb5_child" scontext=system_u:system_r:sssd_t:s0
> > > tcontext=system_u:system_r:unconfined_service_t:s0 tclass=key
> > permissive=0
> > >
> > >
> > > type=SYSCALL msg=audit(1475114921.376:90787): arch=x86_64 syscall=keyctl
> > > success=yes exit=EINTR a0=b a1=333b5463 a2=0 a3=0 items=0 ppid=891
> > pid=8272
> > > auid=4294967295 uid=1388200053 gid=1388200053 euid=1388200053
> > > suid=1388200053 fsuid=1388200053 egid=1388200053 sgid=1388200053
> > > fsgid=1388200053 tty=(none) ses=4294967295 comm=krb5_child
> > > exe=/usr/libexec/sssd/krb5_child subj=system_u:system_r:sssd_t:s0
> > key=(null)
> > >
> > > Hash: krb5_child,sssd_t,unconfined_service_t,key,read
> > >
> > > 
> > 
> > >
> > > SELinux is preventing /usr/libexec/sssd/krb5_child from view access on
> > the
> > > key Unknown.
> > >
> > > *  Plugin catchall (100. confidence) suggests
> > > **
> > >
> > > If you believe that krb5_child should be allowed view access on the
> > Unknown
> > > key by default.
> > > Then you should report this as a bug.
> > > You can generate a local policy module to allow this access.
> > > Do
> > > allow this access for now by executing:
> > > # grep krb5_child /var/log/audit/audit.log | audit2allow -M mypol
> > > #

Re: [Freeipa-users] SELinux errors with sssd-krb5-common-1.13.0-40.el7_2.12.x86_64

[Sumit Bose]

On Thu, Sep 29, 2016 at 12:47:34AM -0400, Prasun Gera wrote:
> I started seeing some selinux errors on one of my RHEL 7 clients recently
> (possibly after a recent yum update ?), which prevents users from logging
> in with passwords. I've put SELinux in permissive mode for now. Logs follow

This sounds like https://bugzilla.redhat.com/show_bug.cgi?id=1301686 .
Would you mind adding your findings and the SSSD logs as described in
https://bugzilla.redhat.com/show_bug.cgi?id=1301686#c2 to the bugzilla
ticket.

Thank you.

bye,
Sumit

> 
> 
> SELinux is preventing /usr/libexec/sssd/krb5_child from read access on the
> key Unknown.
> 
> *  Plugin catchall (100. confidence) suggests
> **
> 
> If you believe that krb5_child should be allowed read access on the Unknown
> key by default.
> Then you should report this as a bug.
> You can generate a local policy module to allow this access.
> Do
> allow this access for now by executing:
> # grep krb5_child /var/log/audit/audit.log | audit2allow -M mypol
> # semodule -i mypol.pp
> 
> 
> Additional Information:
> Source Contextsystem_u:system_r:sssd_t:s0
> Target Contextsystem_u:system_r:unconfined_service_t:s0
> Target ObjectsUnknown [ key ]
> Sourcekrb5_child
> Source Path   /usr/libexec/sssd/krb5_child
> Port  
> Host  
> Source RPM Packages   sssd-krb5-common-1.13.0-40.el7_2.12.x86_64
> Target RPM Packages
> Policy RPMselinux-policy-3.13.1-60.el7_2.9.noarch
> Selinux Enabled   True
> Policy Type   targeted
> Enforcing ModePermissive
> Host Name example.com
> Platform  Linux example.com 4.4.19-1.el7.x86_64
>   #1 SMP Mon Aug 29 18:38:32 EDT 2016 x86_64
> x86_64
> Alert Count   38
> First Seen2016-09-28 18:37:43 EDT
> Last Seen 2016-09-28 22:08:41 EDT
> Local ID  aa5271fa-f708-46b0-a382-fb1f90ce8973
> Raw Audit Messages
> type=AVC msg=audit(1475114921.376:90787): avc:  denied  { read } for
>  pid=8272 comm="krb5_child" scontext=system_u:system_r:sssd_t:s0
> tcontext=system_u:system_r:unconfined_service_t:s0 tclass=key permissive=0
> 
> 
> type=SYSCALL msg=audit(1475114921.376:90787): arch=x86_64 syscall=keyctl
> success=yes exit=EINTR a0=b a1=333b5463 a2=0 a3=0 items=0 ppid=891 pid=8272
> auid=4294967295 uid=1388200053 gid=1388200053 euid=1388200053
> suid=1388200053 fsuid=1388200053 egid=1388200053 sgid=1388200053
> fsgid=1388200053 tty=(none) ses=4294967295 comm=krb5_child
> exe=/usr/libexec/sssd/krb5_child subj=system_u:system_r:sssd_t:s0 key=(null)
> 
> Hash: krb5_child,sssd_t,unconfined_service_t,key,read
> 
> 
> 
> SELinux is preventing /usr/libexec/sssd/krb5_child from view access on the
> key Unknown.
> 
> *  Plugin catchall (100. confidence) suggests
> **
> 
> If you believe that krb5_child should be allowed view access on the Unknown
> key by default.
> Then you should report this as a bug.
> You can generate a local policy module to allow this access.
> Do
> allow this access for now by executing:
> # grep krb5_child /var/log/audit/audit.log | audit2allow -M mypol
> # semodule -i mypol.pp
> 
> 
> Additional Information:
> Source Contextsystem_u:system_r:sssd_t:s0
> Target Contextsystem_u:system_r:unconfined_service_t:s0
> Target ObjectsUnknown [ key ]
> Sourcekrb5_child
> Source Path   /usr/libexec/sssd/krb5_child
> Port  
> Host  
> Source RPM Packages   sssd-krb5-common-1.13.0-40.el7_2.12.x86_64
> Target RPM Packages
> Policy RPMselinux-policy-3.13.1-60.el7_2.9.noarch
> Selinux Enabled   True
> Policy Type   targeted
> Enforcing ModePermissive
> Host Name example.com
> Platform  Linux example.com 4.4.19-1.el7.x86_64
>   #1 SMP Mon Aug 29 18:38:32 EDT 2016 x86_64
> x86_64
> Alert Count   10
> First Seen2016-09-28 18:40:00 EDT
> Last Seen 2016-09-28 22:08:41 EDT
> Local ID  22ec0970-9447-444a-9631-69749e4e7226
> Raw Audit Messages
> type=AVC msg=audit(1475114921.376:90789): avc:  denied  { view } for
>  pid=8272 comm="krb5_child" scontext=system_u:system_r:sssd_t:s0
> tcontext=system_u:system_r:unconfined_service_t:s0 tclass=key permissive=0
> 
> 
> type=SYSCALL msg=audit(1475114921.376:90789): arch=x86_64 syscall=keyctl
> success=no exit=EACCES a0=6 a1=2e1c07f1 a2=0 a3=0 items=0 ppid=891 pid=8272
> auid=4294967295 uid=1388200053 

Re: [Freeipa-users] SSH using putty to IPA client

[Sumit Bose]

On Wed, Sep 28, 2016 at 11:30:56AM +0200, Troels Hansen wrote:
> 
> > Yes, this makes sense as well. If you are not in the forest root you
> > first need a cross-realm TGT for your domain and the forest root. Then
> > you need a cross-realm TGT for the forest root and the IPA domain.
> > 
> > As a next step you should see a request to the IPA KDC to get the actual
> > service ticket for the host in the IPA domain.
> 
> Yes, this is the traffic that's never seen in the capture.
> It seems Windows(Putty) never asks for at host ticket for the IPA host. I 
> receive the krbtgt for the IPA domain, but never sees any traffic from the 
> Windows client to IPA, and thus, never receives the host ticket on the 
> Windows client.

Please check the other traffic on the client after receiving the
cross-realm ticket for the IPA domain. Since the client get the name to
the IPA realm from the AD DC in the last response I would expect that it
will try some DNS SRV lookups to find a KDC in the IPA realm.

HTH

bye,
Sumit

> 
> I'm not at all sure how Kerberos works in Putty, but it seems it uses its own 
> Kerberos libraryes and that these fail.
> 
> I Linux not joined to IPA, just installed with kerberos and use dns config in 
> krb5.conf can kinit in the NET domain, and ssh to IPA using kerberos just 
> fine, so it seems the problem just relates to putty.

-- 
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] SSH using putty to IPA client

[Sumit Bose]

On Wed, Sep 28, 2016 at 10:33:43AM +0200, Troels Hansen wrote:
> 
> 
> - On Sep 28, 2016, at 10:06 AM, Sumit Bose sb...@redhat.com wrote:
> > KRB5KRB_ERR-RESPONSE_TOO_BIG is an expected return code here. The
> > Kerberos communication is typically started via UDP. But the PAC data in
> > the ticket is typically larger than a single UPD packet. The KDC tells
> > the client wit KRB5KRB_ERR-RESPONSE_TOO_BIG to switch to tcp so that the
> > response can be reliably send in multiple tcp packets. If
> > KRB5KRB_ERR-RESPONSE_TOO_BIG is the last you see on the wire I would
> > suspect that port 88 tcp is blocked somewhere.
> > 
> 
> 
> Yes, you are absolutely correct. We actually switch to TCP after the initial 
> try on UDP.
> 
> I can see that we send a TGS-REQ over TCP to the AD for the current domain 
> (NET), and AD answers back with a TGS-REP where I can see "KerberosString" 
> tor the root domain (PLACE), and we then ads the DC for PLACE, with a TGS-REQ 
> and get a TGS-REP with KerberosString for the IPA domain.
> 
> So, actually kerberos traffic seems to be OK

Yes, this makes sense as well. If you are not in the forest root you
first need a cross-realm TGT for your domain and the forest root. Then
you need a cross-realm TGT for the forest root and the IPA domain.

As a next step you should see a request to the IPA KDC to get the actual
service ticket for the host in the IPA domain.

bye,
Sumit

-- 
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] SSH using putty to IPA client

[Sumit Bose]

On Wed, Sep 28, 2016 at 09:19:37AM +0200, Troels Hansen wrote:
> 
> 
> - On Sep 26, 2016, at 1:30 PM, Sumit Bose sb...@redhat.com wrote:
> 
> > About the DNS SRV records, did you add matching records for _udp as
> > well? I'm not sure if the AD client will fallback to _tcp if they are
> > missing or just stop?
> > 
> 
> 
> Ok, finally got some time to debug this.
> 
> tcpdump'ing in the IPA server and logging in, and analyzing the traffic in 
> wireshark I can see that some KRB5KDC_ERR_PREAUTH_REQUIRED traffic to both of 
> the KDC's as expected, followed by some AS-REQ and AS-REP, finally followed 
> by KRB5KRB_ERR-RESPONSE_TOO_BIG, source MAC is a Cisco router despite the 
> server being HP, so somewhere in the network a Cisco router is breaking our 
> Kerberos.

KRB5KRB_ERR-RESPONSE_TOO_BIG is an expected return code here. The
Kerberos communication is typically started via UDP. But the PAC data in
the ticket is typically larger than a single UPD packet. The KDC tells
the client wit KRB5KRB_ERR-RESPONSE_TOO_BIG to switch to tcp so that the
response can be reliably send in multiple tcp packets. If
KRB5KRB_ERR-RESPONSE_TOO_BIG is the last you see on the wire I would
suspect that port 88 tcp is blocked somewhere.

HTH

bye,
Sumit

> 
> I'll start hunting a solution somewhere else but IPA..

-- 
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] SSH using putty to IPA client

[Sumit Bose]

On Mon, Sep 26, 2016 at 01:11:49PM +0200, Troels Hansen wrote:
> 
> 
> - On Sep 26, 2016, at 10:18 AM, Sumit Bose sb...@redhat.com wrote:
> 
> > 
> > Have you checked the firewalls? AD clients must be able to talk to the
> > KDC port (88 udp and tcp) on the IPA servers to get service tickets for
> > IPA hosts.
> > 
> 
> 
> KDC ports seems to work  Besides, I don't have a TGT for the IPA (LX) 
> domain, untill I try to SSH to it. I guess I shouldn't be able to if KDC 
> traffic was blocked?

The cross-realm TGT 'krbtgt/LX.DR.DK @ PLACE.DR.DK' is issued by the AD
DC. So this is not indication that the IPA KDC can be reached by the AD
client.

Do you see and log messages in the krb5kdc.log on the IPA server? If it
is not the firewall I would suggest to record the IP traffic of the AD
client and check what it tries to do after the AD DC send the
cross-realm TGT.

About the DNS SRV records, did you add matching records for _udp as
well? I'm not sure if the AD client will fallback to _tcp if they are
missing or just stop?

HTH

bye,
Sumit

-- 
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] SSH using putty to IPA client

[Sumit Bose]

On Mon, Sep 26, 2016 at 09:25:46AM +0200, Troels Hansen wrote:
> After we installed a new set of IPA servers for prod, and joined AD using 
> username and password to have AD create a correct suffix routing everythin 
> seems to work, and the suffix routing is created correctly on AD. 
> 
> However, trying to SSH from Windows using Putty and kerberos fails: 
> 
> Putty log shows: 
> Event Log: GSSAPI authentication initialisation failed 
> Event Log: No authority could be contacted for authentication.The domain name 
> of the authenticating party could be wrong, the domain could be unreachable, 
> or there might have been a trust relationship failure. 
> 
> DNS is on AD (manually added, and IPA have no DNS installed. 
> 
> Kerberos DNS is correct: 
> 
> # dig _kerberos._tcp.lx.dr.dk SRV 
>  
> ;; ANSWER SECTION: 
> _kerberos._tcp.lx.dr.dk. 3600 IN SRV 0 100 88 ipa01.lx.dr.dk. 
> _kerberos._tcp.lx.dr.dk. 3600 IN SRV 0 100 88 ipa02.lx.dr.dk. 
> 
> ;; ADDITIONAL SECTION: 
> ipa01.lx.dr.dk. 3600 IN A x.y.z.135 
> ipa02.lx.dr.dk. 3600 IN A x.y.z.134 
> 
> 
> # dig _kerberos._tcp.dc._msdcs.lx.dr.dk SRV 
> ... 
> ;; ANSWER SECTION: 
> _kerberos._tcp.dc._msdcs.lx.dr.dk. 3600 IN SRV 0 100 88 ipa02.lx.dr.dk. 
> _kerberos._tcp.dc._msdcs.lx.dr.dk. 3600 IN SRV 0 100 88 ipa01.lx.dr.dk. 
> 
> ;; ADDITIONAL SECTION: 
> ipa02.lx.dr.dk. 3600 IN A x.y.z.134 
> ipa01.lx.dr.dk. 3600 IN A x.y.z.135 
> 
> 
> Klist on Windows shows I have a TGT for the LX domain (but only a TGT), sorry 
> for the danish. 
> 
> #0> Klient: drextrha @ NET.DR.DK 
> Server: krbtgt/LX.DR.DK @ PLACE.DR.DK 
> KerbTicket-krypteringstype: AES-256-CTS-HMAC-SHA1-96 
> Billetflag 0x40a5 -> forwardable renewable pre_authent ok_as_delegate 
> name_canonicalize 
> Starttidspunkt: 9/21/2016 14:58:36 (lokal) 
> Sluttidspunkt: 9/21/2016 23:16:09 (lokal) 
> Fornyelsestidspunkt: 9/28/2016 13:16:09 (lokal) 
> Sessionsnøgletype: AES-256-CTS-HMAC-SHA1-96 
> 
> 
> I can't see whats wrong and can't seem to find out whats wrong? 
> Suggestions welcome :-) 

Have you checked the firewalls? AD clients must be able to talk to the
KDC port (88 udp and tcp) on the IPA servers to get service tickets for
IPA hosts.

HTH

bye,
Sumit

> -- 
> 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] key + 2FA (password+OTP) is not working

[Sumit Bose]

On Thu, Sep 22, 2016 at 08:17:21AM +, Deepak Dimri wrote:
> Hi All,
> 
> 
> I am trying hard to get my 2FA working with FreeIPA but every effort of mine 
> going waste! I have referred earlier forum emails but could not find any good 
> reply on the issue i am facing.
> 
> 
> This is what i am trying
> 
> 
> I have a test user created in my IPA server enabled with Two factor 
> authentication (password + OTP) and has ssh public key added in its profile.  
> I want this test user to ssh into my ipa client (ubuntu 14.04) using  key + 
> password + OTP. I woudl ceryainly prefer just the key+  OTP only ( no 
> password) but that seems far sighted as i cannot even make it work with what 
> it supposed to work password + OTP.
> 
> 
> My /etc/ssh/sshd_conf file has almost everything default  except i added 
> these two lines at the end of it
> 
> Match Group testusergroup
> 
>AuthenticationMethods publickey,password:pam 
> publickey,keyboard-interactive:pam
> 
> i also tried with below but no luck
> 
> Match Group testusergroup
> 
>  AuthenticationMethods publickey,keyboard-interactive
> 
> 
> my /etc/pam.d/sshd has these two changes, rest i kept default:
> 
> 
> # Standard Un*x authentication.
> 
> #@include common-auth
> 
> 
> auth required pam_sss.so
> 
> 
> Now when i try to ssh into ipa client i either keep getting promptS for the 
> password or it gets into a loop asking me to change the password ;complaining 
> falsely that it has expired. I have tried multiple combinations of 
> configurations by referring earlier email threads but none i found helpful. I 
> cant make simple 2FA login to work with freeIPA. Normal password and key 
> works just fine. its the 2FA which does not work for me.
> 
> 
> Would really be thankful if some one can help me with this issue.. is there 
> any good freeIPA 2FA configuration document that i can refer?

Please add debug_level=10 to the [pam] and [domain/...] section of
sssd.conf, restart SSSD, re-run the authentication and send the
generated debug logs together with your sssd.conf and the full
/etc/pam.d/sshd. Please see
https://fedorahosted.org/sssd/wiki/Troubleshooting for details.

> 
> What should the steps for it work seamlessly?

In general it should work out of the box with SSSD's ipa provider.

bye,
Sumit

> 
> 
> Many Thanks,
> 
> Deepak
> 

> -- 
> 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] SSH public user's key stored in AD POSIX attribute

[Sumit Bose]

On Wed, Sep 21, 2016 at 09:47:12AM +0200, Jan Karásek wrote:
> Hi, 
> 
> I have a question about the IPA-AD trust scenario where POSIX attributes are 
> store in AD. 

Although I describe some possible solution below I wonder if using IPA
overrides which allow to add public ssh keys for AD user would work for
you as well? 

> 
> I would like to know if it's possible to store public SSH user key in Active 
> Directory in some user's object attribute - the same way as uidNumber or 
> loginShell. I can't find any suitable attribute for ssh in AD schema but the 
> uidNumber,gidNumber and others are already presented (win2012). 

In general it is possible either extend the schema or use an existing
attribute, see e.g.
https://social.technet.microsoft.com/Forums/en-US/8aa28e34-2007-49fe-a689-e28e19b2757b/is-there-a-way-to-link-ssh-key-in-ad?forum=winserverDS
for details.

But given the recent activities in areas of Powershell and OpenSSH for
Windows I wonder if there might be some "official" attributes coming
sooner or later. Currently I'm not aware of any plans here but maybe
other readers on the list have more insight here?

> 
> So is there any chance to extend AD schema and let the IPA server get public 
> ssh user's key from AD the same way as other POSIX attributes ? Is it IPA 
> ready for that and how that attribute should be named in AD ? 

You have to configure SSSD on the IPA server to read the attribute and
forward it to the clients, for this you need (at least) to add

[domain/EXAMPLE]
ldap_user_extra_attrs = adAttributeName:sshPublicKey

(see sssd-ldap man page for details)

bye,
Sumit

> 
> Thanks, 
> 
> Jan 

> -- 
> 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] In webgui, ID Views slow, to crashingly slow

[Sumit Bose]

On Tue, Sep 20, 2016 at 09:33:21AM +0300, Alexander Bokovoy wrote:
> On Tue, 20 Sep 2016, Martin Babinsky wrote:
> > On 09/20/2016 12:17 AM, Simpson Lachlan wrote:
> > > > -Original Message-
> > > > 
> > > > On 09/19/2016 03:12 AM, Lachlan Musicman wrote:
> > > > > Hi
> > > > > 
> > > > > Sometimes when I visit the ID Views page in the webgui, it is
> > > > > crushingly slow, and often it times out.
> > > > > 
> > > > > Centos 7, ipa --version
> > > > > VERSION: 4.2.0, API_VERSION: 2.156
> > > > > 
> > > > > Is there a reason, can I do something to fix this?
> > > > > 
> > > > 
> > > > What kind of ID Views do you use? Do you use them to  override AD users?
> > > > Is there any useful info in '/var/log/httpd/error_log'?
> > > 
> > > There is the single ID View Name, Default Trust View, and in that we have 
> > > a number of users over riding the AD usernames and home dirs.
> > > 
> > > The httpd error log is relatively large, tbh, but there's nothing in 
> > > there that looks like an obvious reason. In fact, for an error log, there 
> > > is a hell of a lot of "SUCCESS" messages? The most obvious culprit in the 
> > > error log is jsonserver_session...
> > > 
> > > Next time I see it (I only see it intermittently), I'll grab the logs and 
> > > have a look.
> > > 
> > > Cheers
> > > L.
> > > 
> > > 
> > > 
> > > This email (including any attachments or links) may contain
> > > confidential and/or legally privileged information and is
> > > intended only to be read or used by the addressee.  If you
> > > are not the intended addressee, any use, distribution,
> > > disclosure or copying of this email is strictly
> > > prohibited.
> > > Confidentiality and legal privilege attached to this email
> > > (including any attachments) are not waived or lost by
> > > reason of its mistaken delivery to you.
> > > If you have received this email in error, please delete it
> > > and notify us immediately by telephone or email.  Peter
> > > MacCallum Cancer Centre provides no guarantee that this
> > > transmission is free of virus or that it has not been
> > > intercepted or altered and will not be liable for any delay
> > > in its receipt.
> > > 
> > 
> > One thing that crossed my mind is to check the connectivity to the AD
> > domain controllers. To resolve AD user overrides, FreeIPA uses SSSD to
> > contact AD DCs to do the username -> SID translation. If there is some
> > problem contacting them, then there may be hangs/timeouts when resolving
> > override anchors.
> Internally IPA framework attempts to resolve ID override anchors. We can
> actually optimize this code as ipaOriginalUID attribute contains
> normalized name already, written their when the override is created and
> never changed afterwards. This should speed up the resolution of large
> overrides.
> 
> Martin, can you file a ticket for that? The code in question is
> baseidoverride.convert_anchor_to_human_readable_form() which could
> benefit from passing in entry_attrs and checking ipaoriginaluid there.
> If 'ipaoriginaluid' is missing, do analysis of ipaanchoruuid like it is
> done now.

As an alternative I wonder if the WebUI can be made asynchronous in the
sense that it displays the raw data (the SID in this case) first and run
the lookups in the background and replace the SID when the name is
available. I've seen some Windows tools behaving this when looking up
large numbers of SIDs.

bye,
Sumit

> 
> -- 
> / Alexander Bokovoy
> 
> -- 
> 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] sss / nsswitch

[Sumit Bose]

On Tue, Sep 13, 2016 at 10:13:12AM +0200, Rob Verduijn wrote:
> Hi,
> 
> Thanks that did it.
> 
> Is there a less painfull way to be notified of these changes ?
> 
> My nfs configuration gets broken much more than I like because of changes
> like these.
> I know fedora is supposed to be testing grounds unstable software, but I
> would really like to hear a heads up more often.

The change was mentioned in the upstream release notes of SSSD-1.14.1
https://fedorahosted.org/sssd/wiki/Releases/Notes-1.14.1 but of course I
cannot be expected to read all upstream release note before running 'dnf
update'. 

The change was necessary because before the plugin was in the
sssd-common package and this caused that some nfs dependencies were
pulled in even on systems where nfs is not needed at all. Since neither
SSSD nor nfs-idmap strictly require the plugin the new package is not
automatically installed during update.

bye,
Sumit

> 
> Rob Verduijn
> 
> 2016-09-13 9:03 GMT+02:00 Sumit Bose <sb...@redhat.com>:
> 
> > On Tue, Sep 13, 2016 at 08:51:48AM +0200, Rob Verduijn wrote:
> > > Hi all,
> > >
> > > Yesterday my fedora 24 box received an update for sssd to 1.14.1-2.fc24.
> > >
> > > Then after the reboot the nfs-idmap service told me it couldn't start
> > > because it could not find method sss.
> > >
> > > So I filed a bug report and tried switching the method nsswitch.
> > >
> > > But now all files on my kerberos nfs4 shares belong to nobody:nobodyy
> > again.
> > >
> > > Anybody who has a tip on how to work around this until they fix sssd ?
> >
> > The module got its own sub-package. Please install sssd-nfs-idmap.
> >
> > HTH
> >
> > bye,
> > Sumit
> >
> > >
> > > Cheers
> > > Rob Verduijn
> >
> > > --
> > > 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
> >

-- 
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] sss / nsswitch

[Sumit Bose]

On Tue, Sep 13, 2016 at 08:51:48AM +0200, Rob Verduijn wrote:
> Hi all,
> 
> Yesterday my fedora 24 box received an update for sssd to 1.14.1-2.fc24.
> 
> Then after the reboot the nfs-idmap service told me it couldn't start
> because it could not find method sss.
> 
> So I filed a bug report and tried switching the method nsswitch.
> 
> But now all files on my kerberos nfs4 shares belong to nobody:nobodyy again.
> 
> Anybody who has a tip on how to work around this until they fix sssd ?

The module got its own sub-package. Please install sssd-nfs-idmap.

HTH

bye,
Sumit

> 
> Cheers
> Rob Verduijn

> -- 
> 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] SSH login using putty from Windows to SSSD client in IPA AD trust

[Sumit Bose]

On Wed, Sep 07, 2016 at 09:55:45AM +0200, Troels Hansen wrote:
> 
> 
> - On Sep 7, 2016, at 9:43 AM, Sumit Bose sb...@redhat.com wrote:
> 
> > Additionally please check the klist output on the Windows client. It
> > should show the host principal of the Linux client
> > (host/client.ipa.domain@IPA.DOMAIN). If the principal is there the sshd
> > logs on the Linux client with a high debug level might also have some
> > hints why GSSAPI authentication failed.
> > 
> 
> 
> Hmm, no host tickets. Only krbtgt for the domain and LDAP and CIFS principal 
> for thc DC's

So I guess there is no cross-realm ticket either, i.e.
krbtgt/IPA.DOMAIN@AD.DOMAIN. Can you check on AD if the IPA DNS domain
is listed in the 'Name Suffix Routing' tab in the trust properties of
the IPA domain? Additionally please check if the DNS SRV records like
e.g. _kerberos._udp.ipa.domain can be resolved on the AD side.

HTH

bye,
Sumit

-- 
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] SSH login using putty from Windows to SSSD client in IPA AD trust

[Sumit Bose]

On Wed, Sep 07, 2016 at 10:27:17AM +0300, Alexander Bokovoy wrote:
> On Wed, 07 Sep 2016, Troels Hansen wrote:
> > Running RHEL 7.2, IPA 4.2 and SSSD 1.13, we have set up a IPA-AD trust
> > and trying to get Putty GSSAPI login to work.  In Putty GSSAPI have
> > been enabled, and GSSAPI is enabled in sshd.
> > 
> > Logging in using password from Windows to Linux works, and logging in
> > from Linux to Linux using kerberos works.
> > 
> > AD trust is a follows:
> > 
> > # ipa trust-find
> > 
> > 2 trusts matched
> > 
> > Realm name: net.dr.dk
> > Domain NetBIOS name: NET
> > Domain Security Identifier: S-1-5-21-x--
> > 
> > Realm name: place.dr.dk
> > Domain NetBIOS name: PLACE
> > Domain Security Identifier: S-1-5-21-xx-xx-xxx
> > Trust type: Active Directory domain
> > 
> > Number of entries returned 2
> > 
> > 
> > # ipa trust-show place.dr.dk
> > Realm name: place.dr.dk
> > Domain NetBIOS name: PLACE
> > Domain Security Identifier: S-1-5-21---x
> > Trust direction: Trusting forest
> > Trust type: Active Directory domain
> > 
> > # ipa trust-show net.dr.dk
> > Realm name: net.dr.dk
> > Domain NetBIOS name: NET
> > Domain Security Identifier: S-1-5-21-x--xx
> > 
> > users are located in net.dr.dk.
> > 
> > > From looking at the doc's this should just work... However, can't get
> > > it to work. Am I missing something?
> Make screenshots of PuTTY screens showing what you configured and what
> does not work. You can also ask PuTTY to generate logs.

Additionally please check the klist output on the Windows client. It
should show the host principal of the Linux client
(host/client.ipa.domain@IPA.DOMAIN). If the principal is there the sshd
logs on the Linux client with a high debug level might also have some
hints why GSSAPI authentication failed.

HTH

bye,
Sumit

> 
> -- 
> / Alexander Bokovoy
> 
> -- 
> 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] nfsidmap oddity

[Sumit Bose]

On Fri, Aug 26, 2016 at 08:39:05AM -0400, William Muriithi wrote:
> Morning
> 
> I have been struggling with nfsidmap issue for a couple of days and
> wouldn't mind a fresh eyes.
> 
> Essentially, I have a FreeIPA that has a trust relationship with AD.
> The AD is on domain example-corp.example.com while FreeIPA manages
> eng.example.com.  The problem is, when I login using AD account, the
> nfsidmap seem to think I am on the FreeIPA account.  I have changed
> the idnapd.conf to use AD domain but that doesn't help.
> 
> vi /etc/idmapd.conf
> 
> Domain = example-corp.example.com

Which translation method do you use? SSSD provides an own method which
should be more flexible than the default ones, see iman sss_rpcidmapd
for details.

HTH

bye,
Sumit

> 
> 
> 
> [william@cacti ~]$ ssh 'william@example-corp'@platinum.eng.example.com
> 
> william@example-c...@platinum.eng.example.com's password:
> 
> Last login: Tue Aug 23 11:45:33 2016 from 192.168.20.28
> 
> [will...@example-corp.example.com@platinum ~]$ env | grep USER
> 
> USER=will...@example-corp.example.com
> 
> [will...@example-corp.example.com@platinum ~]$ su
> 
> Password:
> 
> [root@platinum william]# tail /var/log/messages
> 
> Aug 26 08:18:13 platinum nfsidmap[17780]: nss_getpwnam: name
> 'r...@eng.example.com' does not map into domain
> 'example-corp.example.com'
> 
> Aug 26 08:18:13 platinum nfsidmap[17784]: nss_getpwnam: name
> 'will...@eng.example.com' does not map into domain
> 'example-corp.example.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] Unable to ssh after establishing trust

[Sumit Bose]

On Mon, Jul 18, 2016 at 09:21:07PM +, pgb205 wrote:
> Sumit,
> 
> I have set the names of all the Domain Controllers to be resolvable to the IP
> of the one reachable Domain Controller in /etc/hosts
> 
> /etc/hosts:
> Reachable_IP_BOX   172.10.10.1
> DC1172.10.10.1
> DC2172.10.10.1
> ...
> ...

The IP address should come first, please see man hosts for details.

> 
> However, I still see the following
> Marking SRV lookup of service 'gc_addomain.local' as 'neutral'
> Marking server dc1.addomain.local' as 'name not resolved'

Have you tried to add the fully-qualified names (dc1.addomain.local) in
the right format (see above) to /etc/hosts?

> 
> 
> Additionally I have configured 
> [domain/ipa.internal]
>   with 
> subdomain_inherit = ldap_user_principal
> ldap_user_principal = nosuchattr
> 
> 
> As far as your earlier note about seeing ewr-fipa-x1 in logs. That used to be
> the old hostname of the IPA KDC.
> After much troubleshooting I believe I got this fixed by deleting  extra
> folders in
> /var/named/dyndb-ldap/ipa/master
> Right now the only two folders are ipa.internal and .in-addr.arpa.
> I think this is what helped with this issue. but can you please confirm if it
> sounds reasonable.

Not sure how you got the additional directories but if on only have a
single IPA DNS domain the two directories are sufficient.

bye,
Sumit

> 
> 
> Ssh is still failing, possibly due to the problem 1 above. Is there anything
> else I can do to force ipa to pay attention to the /etc/hosts ?
> Or is this some other issue?
> 
> thanks
> ━━━
> From: Sumit Bose <sb...@redhat.com>
> To: pgb205 <pgb...@yahoo.com>
> Cc: Sumit Bose <sb...@redhat.com>; Freeipa-users <freeipa-users@redhat.com>
> Sent: Wednesday, July 13, 2016 5:43 AM
> Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> 
> On Tue, Jul 12, 2016 at 06:40:22PM +, pgb205 wrote:
> > +freeipa-users list
> >
> >  From: pgb205 <pgb...@yahoo.com>
> >  To: Sumit Bose <sb...@redhat.com>
> >  Sent: Tuesday, July 12, 2016 2:12 PM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> >   
> > Sumit, thanks for replying
> > So the first issue is my fault, probably from when I was sanitizing logs. 
> > our active directory domain is ad_domain.local, but users would expect to
> login as userid@ad_domain.com or just userid.for ipa the kerberos realm is
> IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal.
> > ewr-fipa_server used to be old trial server so I am not sure why it's still
> in the dns lookup results. I'll check this part further.
> > Lastly. only the connection to one of the domain controllers on AD side is
> open. As discussed previously with Alexandr BokovoyI forced, in 
> /etc/krb5.conf,
> a connection to this single, accessible domain controller. Are there any other
> files where I would needto lock down the connections between ipa->ad so that
> all traffic goes to specific active directory domain controller?
> > thanks again for replying so quickly.
> 
> Currently it is not possible to specify individual AD DC SSSD on the IPA
> server should talk to. We have ticket
> https://fedorahosted.org/sssd/ticket/2599 to make this possible in some
> later versions of SSSD.
> 
> Currently SSSD uses a DNS SRV lookup like _ldap._tcp.ad_domain.local to
> get a list of AD DC, then picks one to get the next nearest site for the
> IPA domain and finally tries to lookup a DC from the matching site (if
> any).
> 
> According to your logs SSSD was able to find 18 DCs with the SRV lookup.
> A call like
> 
> dig SRV _ldap._tcp.ad_domain.local
> 
> on the IPA server should return the same list of 18 DCs.
> 
> As a work-around, or better a hack, you might want to try to set the IP
> address of all the 18 DC returned to the IP address of the only
> accessible DC in /etc/hosts. This way SSSD should have no chance to
> connect to a different DC.
> 
> bye,
> 
> Sumit
> 
> >
> >  From: Sumit Bose <sb...@redhat.com>
> >  To: pgb205 <pgb...@yahoo.com>
> > Cc: Sumit Bose <sb...@redhat.com>
> >  Sent: Tuesday, July 12, 2016 5:37 AM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> > 
> > On Mon, Jul 11, 2016 at 09:14:03PM +, pgb205 wrote:
> > > Sumit, 
> > > sssd log files attached with debug=10 in all sections.I have attempted
> several logins for comparison as well as kinit commands
> >
> > I came across tw

Re: [Freeipa-users] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'

[Sumit Bose]

On Mon, Jul 18, 2016 at 09:54:37AM -0400, Rob Crittenden wrote:
> Sumit Bose wrote:
> > On Sun, Jul 17, 2016 at 11:21:34PM +0200, Martin Štefany wrote:
> > > On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote:
> > > > On (16/07/16 10:19), Martin Štefany wrote:
> > > > > 
> > > > > Hello Sumit,
> > > > > 
> > > > > seems that upgrade to F24 broke things again. This time no AVCs, 
> > > > > empty SSSD
> > > > > logs, but same problem: 'Error looking up public keys'.
> > > > > 
> > > > > selinux-policy-3.13.1-191.fc24.3.noarch
> > > > > selinux-policy-targeted-3.13.1-191.fc24.3.noarch
> > > > > sssd-1.13.4-3.fc24.x86_64
> > > > > 
> > > > Fedora 23 and fedora 24 has the same version of sssd
> > > > and almost the same version of openssh.
> > > > I have no idea what coudl broke it it there are not any AVCs.
> > > > 
> > > > > 
> > > > > Using debug_level 0x0250 ::
> > > > > 
> > > > For troubleshooting, it would be better to see all
> > > > debug messages. (debug_level = 0xfff0)
> > > 
> > > Hello Lukas,
> > > 
> > > thanks for replying on this, here are debug_level = 0xfff0 messages
> > > 
> > 
> > ...
> > 
> > > (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020):
> > > CERT_VerifyCertificateNow failed [-8179].
> > > (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] 
> > > (0x0040):
> > > cert_to_ssh_key failed.
> > 
> > -8179 translates to "Peer's certificate issuer is not recognized."
> > (http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html).
> > This means the CA certificate which signed the certificate on the
> > Smartcard is missing in /etc/pki/nssdb which is used by default by SSSD.
> > 
> > Recent version of IPA put IPA CA certificates only in /etc/ipa/nssdb,
> > this might be the reason why you see this with F24.
> > 
> > To fix this please either add the needed CA certificates to
> > /etc/pki/nssdb with certutil or add 'ca_db = /etc/ipa/nssdb' to the
> > [ssh] section of sssd.conf if /etc/ipa/nssdb already has all needed CA
> > certificates to validate the Smartcard certificate.
> > 
> > I'm working on a fix for SSSD to handle handle this change
> > automatically, but unfortunately it is not ready yet.
> 
> The client installer should be adding the IPA CA to the system certificate
> store which should be picked up automagically by OpenSSL and NSS
> applications. I think I'd start there to see if that happened.

The responsibility for this was delegated to p11-kit in
11592dde1b232a70f318e01f5271b38890090648. Not sure if it was expected
that p11-kit-proxy will be added to /etc/pki/nssdb by default?

bye,
Sumit

> 
> rob
> 

-- 
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] Ghost ipaSshPubKey in sss_ssh_authorizedkeys or 'Error looking up public keys'

[Sumit Bose]

On Sun, Jul 17, 2016 at 11:21:34PM +0200, Martin Štefany wrote:
> On So, 2016-07-16 at 15:37 +0200, Lukas Slebodnik wrote:
> > On (16/07/16 10:19), Martin Štefany wrote:
> > > 
> > > Hello Sumit,
> > > 
> > > seems that upgrade to F24 broke things again. This time no AVCs, empty 
> > > SSSD
> > > logs, but same problem: 'Error looking up public keys'.
> > > 
> > > selinux-policy-3.13.1-191.fc24.3.noarch
> > > selinux-policy-targeted-3.13.1-191.fc24.3.noarch
> > > sssd-1.13.4-3.fc24.x86_64
> > > 
> > Fedora 23 and fedora 24 has the same version of sssd
> > and almost the same version of openssh.
> > I have no idea what coudl broke it it there are not any AVCs.
> > 
> > > 
> > > Using debug_level 0x0250 ::
> > > 
> > For troubleshooting, it would be better to see all
> > debug messages. (debug_level = 0xfff0)
> 
> Hello Lukas,
> 
> thanks for replying on this, here are debug_level = 0xfff0 messages
> 

...

> (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [cert_to_ssh_key] (0x0020):
> CERT_VerifyCertificateNow failed [-8179].
> (Sun Jul 17 23:17:34 2016) [sssd[ssh]] [decode_and_add_base64_data] (0x0040):
> cert_to_ssh_key failed.

-8179 translates to "Peer's certificate issuer is not recognized."
(http://www-archive.mozilla.org/projects/security/pki/nss/ref/ssl/sslerr.html).
This means the CA certificate which signed the certificate on the
Smartcard is missing in /etc/pki/nssdb which is used by default by SSSD.

Recent version of IPA put IPA CA certificates only in /etc/ipa/nssdb,
this might be the reason why you see this with F24.

To fix this please either add the needed CA certificates to
/etc/pki/nssdb with certutil or add 'ca_db = /etc/ipa/nssdb' to the
[ssh] section of sssd.conf if /etc/ipa/nssdb already has all needed CA
certificates to validate the Smartcard certificate. 

I'm working on a fix for SSSD to handle handle this change
automatically, but unfortunately it is not ready yet.

HTH

bye,
Sumit

> 
> > > 
> > > $ /usr/bin/sss_ssh_authorizedkeys martin
> > > Error looking up public keys
> > > 
> > And try to run strace with sss_ssh_authorizedkeys
> > 
> > LS
> 
> 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] HBAC and AD users

[Sumit Bose]

On Thu, Jul 14, 2016 at 11:47:41AM +1000, Lachlan Musicman wrote:
> Ok, I have some logs of sssd 1.13.0 not working. Same values as before:
> 
> FreeIPA server: Centos 7, ipa 4.2, API_VERSION 2.156
> 
> Installed Packages
> Name: ipa-server
> Arch: x86_64
> Version : 4.2.0
> Release : 15.0.1.el7.centos.17
> Size: 5.0 M
> Repo: installed
> >From repo   : updates
> Summary : The IPA authentication server
> 
> 
> Successfully joined in one way trust to AD.
> 
> Successfully have added hosts (Centos 7, sssd 1.13.0).
> 
> 
> [root@vmpr-linuxidm ~]# ipa hbacrule-find
> 
> 5 HBAC rules matched
> 
> 
>   Rule name: allow_all
>   User category: all
>   Host category: all
>   Service category: all
>   Description: Allow all users to access any host from any host
>   Enabled: FALSE
> 
> ...
> 
>   Rule name: ssh to galaxy
>   Service category: all
>   Description: Allows ssh to galaxy server
>   Enabled: TRUE
>   User Groups: ad_users
>   Hosts: papr-res-galaxy.unix.petermac.org.au
> 
> 
> 
> 
> With allow_all HBAC rule enabled, can login every time with
> 
> ssh user@ad_domain@unix_host
> 
> If I implement a HBAC rule "ssh to galaxy" as per above, with:
> 
> ad_users is a POSIX group with a GID. It has one member, the group
> 
> ad_external an external group with a single, external, member
> 
> pmc-res-ipaus...@petermac.org.au
> 
> which is an AD group containing all the users that should have access to
> the host.
> 
> 
> With allow_all disabled and "ssh to galaxy" enabled, some users can login
> and some can't. There is no discernable pattern that might explain why some
> are discriminated against.
> 
> Here is the test from the server:
> 
> [root@vmpr-linuxidm ~]# ipa hbactest --user=sandsjor...@petermac.org.au
> --host=papr-res-galaxy.unix.petermac.org.au --service=sshd
> 
> Access granted: True
> 
>   Matched rules: ssh to galaxy
>   Not matched rules: Computing Cluster
>   Not matched rules: FACS Computing
> 
> I've installed ipa-admintools on the host in question and got the same
> result.
> 
> To be on the safe side/tick all boxes, I have cleared the cache on the host
> in question:
> 
> systemctl stop sssd
> sss_cache -E
> systemctl start sssd
> 
> and confirmed success with a status check.
> 
> When the user tries to login, it fails.
> 
> Log is here:
> 
> http://dpaste.com/0VAFNPH
> 
> 
> The top is where the negotiating starts to the best of my knowledge.
> 
> The attempts fails, with no information that is useful to me:
> 
> 230 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_get_category] (0x0200): Category is set to 'all'.
> 231 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_thost_attrs_to_rule] (0x1000): Processing target hosts for rule [ssh
> to galaxy]
> 232 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_shost_attrs_to_rule] (0x0400): Processing source hosts for rule [ssh
> to galaxy]
> 233 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [hbac_eval_user_element] (0x1000): [3] groups for [
> sandsjor...@petermac.org.au]

According to the HBAC evaluation the user is a member of 3 groups. Is
this the expected number?

Can you check if 'id sandsjor...@petermac.org.au' returns the expected
list of groups on the client and the IPA server? (The client does not
talk to AD directly only to the IPA server, so if something is already
missing on the server it cannot be seen on the client as well).

Can you send me the SSSD cache file from the client
/var/lib/sss/db/cache_unix.petermac.org.au.ldb after the login attempt?
Since it might contain password hashes you might want to remove
lines with 'cachedPassword' before

bye,
Sumit


> 234 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [ipa_hbac_evaluate_rules] (0x0080): Access denied by HBAC rules
> 235 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [be_pam_handler_callback] (0x0100): Backend returned: (0, 6, )
> [Success (Permission denied)]
> 236 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [be_pam_handler_callback] (0x0100): Sending result [6][petermac.org.au]
> 237 (Thu Jul 14 10:40:59 2016) [sssd[be[unix.petermac.org.au]]]
> [be_pam_handler_callback] (0x0100): Sent result [6][petermac.org.au]
> 
> 
> Cheers
> L.
> 
> 
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
> 
> - Grace Hopper
> 
> On 12 July 2016 at 09:08, Lachlan Musicman <data...@gmail.co

Re: [Freeipa-users] Unable to ssh after establishing trust

[Sumit Bose]

On Tue, Jul 12, 2016 at 06:40:22PM +, pgb205 wrote:
> +freeipa-users list
> 
>   From: pgb205 <pgb...@yahoo.com>
>  To: Sumit Bose <sb...@redhat.com> 
>  Sent: Tuesday, July 12, 2016 2:12 PM
>  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
>
> Sumit, thanks for replying
> So the first issue is my fault, probably from when I was sanitizing logs. 
> our active directory domain is ad_domain.local, but users would expect to 
> login as userid@ad_domain.com or just userid.for ipa the kerberos realm is 
> IPA_DOMAIN.INTERNAL and domain is ipa_domain.internal.
> ewr-fipa_server used to be old trial server so I am not sure why it's still 
> in the dns lookup results. I'll check this part further.
> Lastly. only the connection to one of the domain controllers on AD side is 
> open. As discussed previously with Alexandr BokovoyI forced, in 
> /etc/krb5.conf, a connection to this single, accessible domain controller. 
> Are there any other files where I would needto lock down the connections 
> between ipa->ad so that all traffic goes to specific active directory domain 
> controller?
> thanks again for replying so quickly.

Currently it is not possible to specify individual AD DC SSSD on the IPA
server should talk to. We have ticket
https://fedorahosted.org/sssd/ticket/2599 to make this possible in some
later versions of SSSD. 

Currently SSSD uses a DNS SRV lookup like _ldap._tcp.ad_domain.local to
get a list of AD DC, then picks one to get the next nearest site for the
IPA domain and finally tries to lookup a DC from the matching site (if
any).

According to your logs SSSD was able to find 18 DCs with the SRV lookup.
A call like

dig SRV _ldap._tcp.ad_domain.local

on the IPA server should return the same list of 18 DCs.

As a work-around, or better a hack, you might want to try to set the IP
address of all the 18 DC returned to the IP address of the only
accessible DC in /etc/hosts. This way SSSD should have no chance to
connect to a different DC.

bye,
Sumit

> 
>   From: Sumit Bose <sb...@redhat.com>
>  To: pgb205 <pgb...@yahoo.com> 
> Cc: Sumit Bose <sb...@redhat.com>
>  Sent: Tuesday, July 12, 2016 5:37 AM
>  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
>   
> On Mon, Jul 11, 2016 at 09:14:03PM +, pgb205 wrote:
> > Sumit, 
> > sssd log files attached with debug=10 in all sections.I have attempted 
> > several logins for comparison as well as kinit commands
> 
> I came across two issues in the logs.
> 
> First it looks like you use 'user@AD_DOMAIN.LOCAL' at the login prompt
> but there seem to be an alternative domain suffix 'AD_DOMAIN.COM' on the
> AD side and user principal attributes 'user@AD_DOMAIN.COM'. Currently
> FreeIPA cannot resolve those principals correctly. It was planned for
> IPA 4.4.0 and SSSD 1.14.0 but because of an issue found in 4.4.0 it will
> be available (hopefully) with IPA 4.4.1 and SSSD 1.14.1. In the meantime
> please try to work-around suggested at the end of
> http://osdir.com/ml/freeipa-users/2016-01/msg00304.html . When trying to
> authenticate with user@AD_DOMAIN.COM SSSD looks for a server called
> ewr-fipa_server.ad_domain.com but cannot find it an return the error code
> for "Cannot contact any KDC for requested realm".
> 
> Second there are some issues access AD DCs via LDAP. SSSD tries to
> connect to mm-sfdc01.ad_domain.local and mm-tokyo-02.ad_domain.local but
> both fails. It is not clear from the logs if already the DNS lookup for
> those fails or if the connection itself runs into a timeout. In the
> former case you should make sure that the names can be resolved in the
> IPA server in the latter you can try to increase ldap_network_timeout
> (see man sssd-ldap for details). Since SSSD cannot connect to the DCs it
> switches the AD domains to offline. The authentication request is
> handled offline as well but since there are no cached credentials you
> get the permission denied error.
> 
> HTH
> 
> bye,
> Sumit
> 
> > 
> >      From: Sumit Bose <sb...@redhat.com>
> >  To: pgb205 <pgb...@yahoo.com> 
> > Cc: "Freeipa-users@redhat.com" <Freeipa-users@redhat.com>
> >  Sent: Monday, July 11, 2016 3:06 AM
> >  Subject: Re: [Freeipa-users] Unable to ssh after establishing trust
> >    
> > On Mon, Jul 11, 2016 at 03:46:57AM +, pgb205 wrote:
> > > I have successfully established trust and am able to obtain ticket 
> > > granting ticketkinit user@AD_DOMAIN.COMI can also do kinit 
> > > admin@IPA_DOMAIN.COMssh admin@IPA_DOMAIN.COM also works
> > > however, ssh user@AD_DOMAIN.COM or user@ad_domain.com fails
> > > I have checked that there are no h

Re: [Freeipa-users] IPA HBAC access using SSSD for user in trusted AD domain (RHEL 6.8)

[Sumit Bose]

On Wed, Jul 13, 2016 at 08:37:44AM +0200, Jakub Hrozek wrote:
> On Wed, Jul 13, 2016 at 09:10:07AM +0300, Alexander Bokovoy wrote:
> > On Tue, 12 Jul 2016, Sullivan, Daniel [AAA] wrote:
> > > Justin,
> > > 
> > > I really appreciate you taking the time to respond to me.  This problem
> > > is driving me crazy and I will certainly take any help I can get. My
> > > suspicion is that the external user group in the policy below was
> > > causing the log entry you specified, removing it from the policy does
> > > not remediate the problem, even after flushing the client cache.
> > > 
> > > The way I have this setup is as follows:
> > > 
> > > 1) I created a POSIX group in IPA named
> > > 'cri-cri_server_administrators_ipa' and allowed IPA to assign the GID.
> > > 2) I created an external group in IPA named
> > > 'cri-cri_server_administrators_external’ and added the AD group in the
> > > trusted domain as an external member to this group
> > > (cri-cri_server_administrat...@bsdad.uchicago.edu).
> > > 3) I added the group cri-cri_server_administrators_external' as a
> > > member of 'cri-cri_server_administrators_ipa’
> > > 
> > > The HBAC rule is configured as (removing the external group does not
> > > seem to make a difference).
> > > 
> > > [root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 
> > > 'cri-cri_server_administrators_allow_all'
> > >  Rule name: cri-cri_server_administrators_allow_all
> > >  Host category: all
> > >  Service category: all
> > >  Description: Allow anyone in 
> > > cri-cri_server_administrat...@bsdad.uchicago.edu
> > >  to login to any machine
> > >  Enabled: TRUE
> > >  User Groups: cri-cri_server_administrators_external, 
> > > cri-cri_server_administrators_ipa
> > > [root@cri-ksysipadcp2 a.cri.dsullivan]#
> > > 
> > > For example, the problem still persists when the policy is configured in 
> > > this manner:
> > > 
> > > [root@cri-ksysipadcp2 a.cri.dsullivan]# ipa hbacrule-show 
> > > 'cri-cri_server_administrators_allow_all'
> > >  Rule name: cri-cri_server_administrators_allow_all
> > >  Host category: all
> > >  Service category: all
> > >  Description: Allow anyone in 
> > > cri-cri_server_administrat...@bsdad.uchicago.edu to login to any machine
> > >  Enabled: TRUE
> > >  User Groups: cri-cri_server_administrators_ipa
> > > 
> > > And my login validates against the host in question as follows:
> > > 
> > > As I said I have this working consistently (i.e. can flush the cash) on
> > > another host with the same exact version of IPA and SSSD.  Here is a
> > > validation of hbactest (works with either of the two policy
> > > configurations above).
> > I think you problems are related to this snippet of your domain log
> > where SSSD on IPA client was unable to add membership of your user to
> > any of these groups:
> > 

...

> > 
> > as result, the user is viewed by SSSD on this IPA client as not
> > belonging to the cri-cri_server_administrat...@bsdad.uchicago.edu group
> > and thus, HBAC rule validation on this client fails.
> 
> First, we have some debug messages in this part of sssd that can really
> use some improvement. That is, some debug messages are expected to
> report failures and we recover from them later.
> 
> But in general Alexander is right. Does 'id
> a.cri.dsulli...@bsdad.uchicago.edu' report the user as a member of the
> group that should be allowing access?
> 
> If not, I would suggest to run:
> 1) sss_cache -E on both server and client (don't remove the cache,
> please)
> 2) truncate the logs on server and client
> 3) run id a.cri.dsulli...@bsdad.uchicago.edu on the client
> then send us the logs from that single id run..

If some of the IPA group memberships are missing you might hit
https://bugzilla.redhat.com/show_bug.cgi?id=1304333 which is not fixed
in the IPA version you use (ipa-4.2.0-15.el7_2.6.1).

Mabye upgrading the server helps?

bye,
Sumit

-- 
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] HBAC and AD users

[Sumit Bose]

On Tue, Jul 12, 2016 at 09:08:01AM +1000, Lachlan Musicman wrote:
> Alex, Sumit,
> 
> Which log levels would you recommend for sssd to help debug this issue?
> 
> We've been using 7, but I just realised that it's not an increasing scale
> but bitmasked...

It is both 0-9 is increasing scale while values above 16 are treated as
bitmask. Please just use 9 to get all messages.

bye,
Sumit

> 
> cheers
> L.
> 
> --
> The most dangerous phrase in the language is, "We've always done it this
> way."
> 
> - Grace Hopper
> 
> On 11 July 2016 at 17:15, Sumit Bose <sb...@redhat.com> wrote:
> 
> > On Mon, Jul 11, 2016 at 04:55:37PM +1000, Lachlan Musicman wrote:
> > > On 11 July 2016 at 16:44, Alexander Bokovoy <aboko...@redhat.com> wrote:
> > >
> > > > On Mon, 11 Jul 2016, Lachlan Musicman wrote:
> > > >
> > > >> Hola,
> > > >>
> > > >> Centos 7, up to date.
> > > >>
> > > >> [root@linuxidm ~]# ipa --version
> > > >> VERSION: 4.2.0, API_VERSION: 2.156
> > > >>
> > > >> One way trust is successfully established, can login with
> > > >>
> > > >> ssh usern...@domain1.com@server1.domain2.com
> > > >>
> > > >> Am testing to get HBAC to work.
> > > >>
> > > >> I've noticed that with the Allow All rule in effect, the following
> > set up
> > > >> is sufficient:
> > > >>
> > > >> add external group "ad_external"
> > > >> add internal group, "ad_internal", add ad_external as a group member
> > of
> > > >> ad_internal
> > > >>
> > > >> AD users can now successfully login to any server.
> > > >>
> > > >> When I tried to set up an HBAC, I couldn't get that set up to work, I
> > > >> needed to complete the extra step of adding AD users explicitly to the
> > > >> "external member" group of the external group.
> >
> > yes, this is expected you either have to add AD users or groups to the
> > external groups.
> >
> > > >>
> > > >> I also note that this seems to be explicitly user based, not group
> > based?
> > > >> IE, I can add lach...@domain1.com to the external members of
> > ad_external
> > > >> and that works, but adding the group server_adm...@domain1.com (as
> > seen
> > > >> in
> > > >> `id lach...@domain1.com`) doesn't allow all members access.
> >
> > Since it looks you are using FreeIPA 4.2 you might hit
> > https://fedorahosted.org/freeipa/ticket/5573 . But SSSD logs, especially
> > the part where the HBAC rules are evaluated would help to understand the
> > issue better.
> >
> > > >>
> > > >> Does that sound correct?
> > > >>
> > > > No, it does not.
> > > > HBAC evaluation and external group merging/resolution is done by SSSD.
> > > > Use https://fedorahosted.org/sssd/wiki/Troubleshooting to produce logs
> > > > that can help understanding what happens there.
> > > >
> > > > What SSSD version do you have on both IPA client and IPA server?
> > >
> > >
> > >
> > > 1.13.0 on both client and server.
> > >
> > > To be honest, we have ratcheted up the logs and it doesn't help that
> > much.
> > > We just got lots of "unsupported PAM command [249]"
> >
> > This is unrelated, I assume this happens when trying to store the hashed
> > password to the cache. This message is remove in newer releases.
> >
> > bye,
> > Sumit
> >
> > >
> > > Cheers
> > > L.
> >
> > > --
> > > 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

-- 
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