Re: [Freeipa-users] IPA different ID results on different nodes

2013-06-04 Thread Aly Khimji 
I re-logged in this morning into the server and i see the following on the
server
Any thoughts?

Thx again.

SERVER:
-sh-4.1$ id
uid=59401108(akhi...@corpnonprd..com) gid=59401108(
akhi...@corpnonprd..com) groups=59401108(akhi...@corpnonprd..com)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

CLIENT:
-sh-4.1$ id
uid=59401108(akhi...@corpnonprd..com) gid=59401108(
akhi...@corpnonprd..com)
groups=59401108(akhi...@corpnonprd..com),59400512(domain
adm...@corpnonprd..com),59400513(domain us...@corpnonprd..com
),59401123(mirra-supapp-admin-corp-...@corpnonprd..com),162200012(mirra-supapp-admin-nix-cde)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
-sh-4.1$

CLIENT LOG:
(Tue Jun  4 09:35:51 2013) [sssd[be[nix.corpnonprd..com]]]
[ipa_s2n_get_user_done] (0x0040): s2n exop request failed.
(Tue Jun  4 09:35:51 2013) [sssd[be[nix.corpnonprd..com]]]
[sdap_id_op_done] (0x0200): communication error on cached connection,
moving to next server
(Tue Jun  4 09:35:51 2013) [sssd[be[nix.corpnonprd..com]]]
[acctinfo_callback] (0x0100): Request processed. Returned 3,110,User lookup
failed
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[be_get_account_info] (0x0100): Got request for [3][1][name=akhimji]
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[acctinfo_callback] (0x0100): Request processed. Returned 3,95,User lookup
failed
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[be_pam_handler] (0x0100): Got request with the following data
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[pam_print_data] (0x0100): command: PAM_AUTHENTICATE
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[pam_print_data] (0x0100): domain: CorpNonPrd..com
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[pam_print_data] (0x0100): user: akhi...@corpnonprd..com
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[pam_print_data] (0x0100): service: sshd
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[pam_print_data] (0x0100): tty: ssh
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[pam_print_data] (0x0100): ruser:
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[pam_print_data] (0x0100): rhost: 10.210.240.246
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[pam_print_data] (0x0100): authtok type: 1
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[pam_print_data] (0x0100): authtok size: 11
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[pam_print_data] (0x0100): newauthtok type: 0
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[pam_print_data] (0x0100): newauthtok size: 0
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[pam_print_data] (0x0100): priv: 1
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[pam_print_data] (0x0100): cli_pid: 10644
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[check_for_valid_tgt] (0x0020): krb5_cc_retrieve_cred failed.
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA'
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[resolve_srv_send] (0x0200): The status of SRV lookup is resolved
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[be_resolve_server_process] (0x0200): Found address for server
didmsvrua01.nix.corpnonprd..com: [10.137.216.162] TTL 1200
(Tue Jun  4 09:36:17 2013) [sssd[be[nix.corpnonprd..com]]]
[krb5_find_ccache_step] (0x0080): Saved ccache
FILE:/tmp/krb5cc_59401108_opsH3I if of different type than ccache in
configuration file, reusing the old ccache
(Tue Jun  4 09:36:18 2013) [sssd[be[nix.corpnonprd..com]]]
[fo_set_port_status] (0x0100): Marking port 389 of server '
didmsvrua01.nix.corpnonprd..com' as 'working'
(Tue Jun  4 09:36:18 2013) [sssd[be[nix.corpnonprd..com]]]
[set_server_common_status] (0x0100): Marking server '
didmsvrua01.nix.corpnonprd..com' as 'working'
(Tue Jun  4 09:36:18 2013) [sssd[be[nix.corpnonprd..com]]]
[be_pam_handler_callback] (0x0100): Backend returned: (0, 0, )
[Success]
(Tue Jun  4 09:36:18 2013) [sssd[be[nix.corpnonprd..com]]]
[be_pam_handler_callback] (0x0100): Sending result [0][CorpNonPrd..com]
(Tue Jun  4 09:36:18 2013) [sssd[be[nix.corpnonprd..com]]]
[be_pam_handler_callback] (0x0100): Sent result [0][CorpNonPrd..com]
(Tue Jun  4 09:36:18 2013) [sssd[be[nix.corpnonprd..com]]]
[child_sig_handler] (0x0100): child [10648] finished successfully.
(Tue Jun  4 09:36:18 2013) [sssd[be[nix.corpnonprd..com]]]
[be_get_account_info] (0x0100): Got request for [3][1][name=akhimji]
(Tue Jun  4 09:36:18 2013) [sssd[be[nix.corpnonprd..com]]]
[acctinfo_callback] (0x0100): *Request processed. Returned 3,95,User lookup
failed*
(Tue Jun  4 09:36:18 2013) [sssd[be[nix.corpnonprd..com]]]
[be_pam_ha

Re: [Freeipa-users] Limiting Host access by UID/GID

2013-06-04 Thread Jakub Hrozek 
On Fri, May 31, 2013 at 08:50:29AM -0700, Chandan Kumar wrote:
> As far as my understanding goes it does not stop even if I disable cache
> credentials. I set following parameters in sssd.conf but still UID 2 is
> able to login.
> 

Sorry, there was some terminology confusion. I didn't ask for disabling
cache credentials, but removing the on-disk cache and starting afresh.

The cache is stored in /var/lib/sss/db/cache_$domname.ldb, so you can mv
or rm it and check again if the IDs are still allowed.

> cache_credentials = False
> krb5_store_password_if_offline = False
> min_id=5000
> max_id=5010
> enumerate = False
> entry_cache_timeout=3
> 
> Package Info:
> Client;
> sssd-client-1.9.2-82.7.el6_4.x86_64
> 
> Server:
> ipa-server-2.2.0-16.el6.x86_64
> 
> Thanks
> Chandan
> 
> On Friday, May 31, 2013, Jakub Hrozek wrote:
> 
> > On Fri, May 31, 2013 at 09:26:40AM -0400, Simo Sorce wrote:
> > > On Fri, 2013-05-31 at 11:55 +0200, Jakub Hrozek wrote:
> > > > On Thu, May 30, 2013 at 07:23:38PM -0400, Dmitri Pal wrote:
> > > > > On 05/30/2013 06:52 PM, Chandan Kumar wrote:
> > > > > > Hello,
> > > > > >
> > > > > > As part of migration from passwd/shadow to IPA, I want to roll out
> > > > > > IPA/SSSD based password first for a small number of users and then
> > for
> > > > > > all. (same goes with host. first small number of host and then
> > all).
> > > > > >
> > > > > > I was trying to limit it using max_id/min_id parameters in sssd
> > but it
> > > > > > does not seems to work the way I expected.
> > > > > > ---
> > > > > > min_id = 5000
> > > > > > max_id = 5100
> > > > > > --
> > > > > > So there is a user "kchandan" with UID/GID 2
> > > > > > --
> > > > > > [root@tipa1 ~]# id kchandan
> > > > > > uid=2(kchandan) gid=2 groups=2
> > > > > > ---
> > > > > >
> > > > > > But It is allowing me to login with that ID with only error showing
> > > > > > GID 2 not found.
> > > > > > ---
> > > > > > ssh 10.2.3.105 -l kchandan
> > > > > > kchandan@10.2.3.105 's password:
> > > > > > id: cannot find name for group ID 2
> > > > > > -
> > > > > >
> > > > > > Is there any way to achieve this?
> > > > >
> > > > > So you want to allow only a subset of users with a specific range to
> > log
> > > > > into the systems controlled by SSSD before you open it to a broader
> > public?
> > > > > I would defer to SSSD gurus but the hack that comes to mind is to
> > > > > configure a simple access provider to limit the access to just the
> > users
> > > > > you care about (man sssd-simple) or configure ldap access provider
> > based
> > > > > on a filter (man sssd-ldap).
> > > >
> > > > Hi,
> > > >
> > > > The user shouldn't be even saved to cache if it's filtered out of
> > range.
> > > >
> > > > But looking at the current NSS code, the entry would have been
> > returned if
> > > > it was saved *before* you changed the min_id/max_id parameters. Could
> > that be
> > > > the case? Can you check if after removing the cache the entry still
> > shows up?
> > > >
> > > > I think that the fact that the entry is returned from cache even if it
> > > > should be filtered out is a bug:
> > > > https://fedorahosted.org/sssd/ticket/1954
> > >
> > > So far we always maintained that if you consistently change
> > > configuration (and a change of ranges is a big change) then it's on the
> > > admin to wipe the cache file.
> >
> > Yes, that's why the ticket is minor. But mostly I don't like the
> > inconsistency where some requests check the ranges even in the responder
> > and some don't.
> >
> > ___
> > Freeipa-users mailing list
> > Freeipa-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> >
> 
> 
> -- 
> 
> --
> http://about.me/chandank

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Logging Failed User logins for Trust Users

2013-06-04 Thread Sumit Bose 
On Mon, Jun 03, 2013 at 04:30:19PM -0400, Dmitri Pal wrote:
> On 06/03/2013 02:23 PM, Aly Khimji wrote:
> > Quick questions guys, 
> >
> > can you advise if there is a particular place(s) successful and failed
> > users authentication is logged? I know from local users I can go
> > through the 389 access logs, but for trust based users can you advise
> > where I would look? I know i see a proper ticket issued in krb5kdc
> > logs, but mainly for failed logins.
> 
> What is the scenario?
> Is this: user from AD logs into a Linux system that is joined into IPA
> via SSSD?
> In this case the authentication happens in AD so the audit trail will be
> there.
> Once this user tries to access a resource in IPA domain there will be a
> record of issuing this user a service ticket in the kerberos log.
> 
> The users always get TGTs from the domain they belong to so the record
> will be in the log of the corresponding KDC.

Are you using ssh to log in to the IPA client or is this a console
login?

In the first case logs from sshd might help. Typically issues here are
related to access checks and mapping the Kerberos principal to a local
user name. See e.g.
http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Edit_.2Fetc.2Fkrb5.conf
how to configure the auth_to_local feature. Please note that Kerberos
principals are handled case sensitive here, i.e. if you AD users name
use upper and lower case you have to use the same case at the ssh login
prompt. Alternatively you can add a .k5login file in the users home
directory on the IPA client.

For console login the sssd logs is the best source to figure out what's
going wrong,

HTH

bye,
Sumit

> 
> 
> >
> > Thx 
> >
> > Aly
> >
> >
> > ___
> > Freeipa-users mailing list
> > Freeipa-users@redhat.com
> > https://www.redhat.com/mailman/listinfo/freeipa-users
> 
> 
> -- 
> Thank you,
> Dmitri Pal
> 
> Sr. Engineering Manager for IdM portfolio
> Red Hat Inc.
> 
> 
> ---
> Looking to carve out IT costs?
> www.redhat.com/carveoutcosts/
> 
> 
> 

> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] IPA different ID results on different nodes

2013-06-04 Thread Sumit Bose 
On Mon, Jun 03, 2013 at 09:22:21PM -0400, Aly Khimji wrote:
> Hey guys,
> 
> Just wanted to say thank you for all your support with everything and
> answering all my questions.
> 
> Just wanted to show you something, maybe you can shed some light..
> Below is my self running the ID command on 2 different nodes (1) the IDM
> server and the other the IDM client. I get two different results of my user
> ID, the client being correct and the server not having the correct groups
> displaying with the ID, and even having one that has been deleted.
> 
> Is there someplace this information in cached? or I can set an invalidator
> so that the information is pulled down or is forced to expire quicker so
> its checked from AD?
> 
> CLIENT:
> -sh-4.1$ hostname
> rhidmclient.nix.corpnonprd..com
> -sh-4.1$ id
> uid=59401108(akhi...@corpnonprd..com) gid=59401108(
> akhi...@corpnonprd..com)
> groups=59401108(akhi...@corpnonprd..com),59400512(domain
> adm...@corpnonprd..com),
> 59400513(domain us...@corpnonprd..com),59401123(
> mirra-supapp-admin-corp-...@corpnonprd..com),
> 162200012(mirra-supapp-admin-nix-cde)
> context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
> 
> 
> SERVER:
> didmsvrua01.nix.corpnonprd..com
> [root@didmsvrua01 ~]# id akhimji@corpnonprd
> uid=59401108(akhi...@corpnonprd..com) gid=59401108(
> akhi...@corpnonprd..com)
> groups=59401108(akhi...@corpnonprd..com),59400513,59400513,59401113(
> s...@corpnonprd..com)
> 
> just a note this group [59401113(s...@corpnonprd..com)] was deleted on
> AD, and correctly doesn't show up on the client, but remains in the server.

Group-memberships are cached for some time by SSSD so I would guess you
see cached data on the server. But during authentication the
group-memberships of a user are updated. Can you check if
s...@corpnonprd..com does away if you log in with akhimji@corpnonprd
on the server?

bye,
Sumit
> 
> Please let me know if you need more info (eg logs, etc..)
> 
> Thx
> 
> Aly

> ___
> Freeipa-users mailing list
> Freeipa-users@redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-users

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users