Hi Many thanks. I attaching the files as otherwise the one that relates to the domain is very large. Curiously though the krb5_child.log is empty (0 bytes) "so it will not be attached".

And I apologize for not paying attention to subject - in Gmail it is a bit fiddly.

Roberts




On 25 October 2013 02:25, <sssd-users-request@lists.fedorahosted.org> wrote:
Send sssd-users mailing list submissions to
        sssd-users@lists.fedorahosted.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.fedorahosted.org/mailman/listinfo/sssd-users
or, via email, send a message with subject or body 'help' to
        sssd-users-request@lists.fedorahosted.org

You can reach the person managing the list at
        sssd-users-owner@lists.fedorahosted.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of sssd-users digest..."


Today's Topics:

   1. Re:  sssd-users Digest, Vol 18, Issue 25 (Jakub Hrozek)
   2. Re:  sssd-users Digest, Vol 18, Issue 25 (Roberts Klotiņš)


----------------------------------------------------------------------

Message: 1
Date: Thu, 24 Oct 2013 16:24:41 +0200
From: Jakub Hrozek <jhrozek@redhat.com>
To: sssd-users@lists.fedorahosted.org
Subject: Re: [SSSD-users] sssd-users Digest, Vol 18, Issue 25
Message-ID: <20131024142441.GG4240@hendrix.redhat.com>
Content-Type: text/plain; charset=utf-8

On Thu, Oct 24, 2013 at 02:01:11PM +0100, Roberts Klotiņš wrote:
> Hi Thanks a lot for looking into this.
>
> As you suspected - there is something that enterprise simple login added
> into the config file file:
>
> [sssd]
> services = nss, pam
> config_file_version = 2
> domains = PEOPLE
>
> [nss]
> filter_users = root
> filter_groups = root
>
> [pam]
>
> [domain/PEOPLE]
> description = PEOPLE AD domain
> id_provider = ad
> auth_provider = ad
> access_provider = ad
> chpass_provider = ad
>
> ad_server = srv1.people.local
> ad_hostname = client1.people.local
> ad_domain = PEOPLE.LOCAL
> case_sensitive = false
>
> enumerate = true
> cache_credentials = true
> simple_allow_users = usr1, usr2

Did you modify the config file anyhow? I find it suprising that there is
both "access_provider=ad" and "simple_allow_users". For the simple allow
users to work, I would have expected "access_provider=simple".

>
> However when I deleted the last line in this file I got the same result.
> /var/log/secure
> datet:42:54 robbie gdm-password]: pam_unix(gdm-password:auth):
> authentication failure; logname=(unknown) uid=0 euid=0 tty=:1 ruser
> = rhost=  user=PEOPLE\usr2
> datet:42:54 robbie gdm-password]: pam_sss(gdm-password:auth):
> authentication failure; logname=(unknown) uid=0 euid=0 tty=:1 ruser=
>  rhost= user=PEOPLE\usr2
> datet:42:54 robbie gdm-password]: pam_sss(gdm-password:auth): received for
> user PEOPLE\usr2: 6 (Permission denied)
> datet:42:59 robbie gdm-password]: pam_unix(gdm-password:auth): conversation
> failed
> datet:42:59 robbie gdm-password]: pam_unix(gdm-password:auth): auth could
> not identify password for [PEOPLE\usr2]
> datet:42:59 robbie gdm-password]: pam_sss(gdm-password:auth):
> authentication failure; logname=(unknown) uid=0 euid=0 tty=:1 ruser=
>  rhost= user=PEOPLE\usr2
> datet:42:59 robbie gdm-password]: pam_sss(gdm-password:auth): received for
> user PEOPLE\usr2: 7 (Authentication failure)
>
> It appears I may need to configure something in pam, but maybe that is not
> the case??

Ah, in the /var/log/secure snippet you send earlier there was also
access denied, which is why I was suspecting the access provider to be
the problem.

Can you put debug_level=7 into the [domain] section, restart the SSSD
and attach the contents of /var/log/sssd/sssd_PEOPLE.log and
/var/log/sssd/krb5_child.log


------------------------------

Message: 2
Date: Fri, 25 Oct 2013 02:25:04 +0100
From: Roberts Klotiņš <roberts.klotins@gmail.com>
To: sssd-users@lists.fedorahosted.org
Subject: Re: [SSSD-users] sssd-users Digest, Vol 18, Issue 25
Message-ID:
        <CALr2nHsFVyoo+GoENWjx99ew3Bjgek47QYU3_MJ0_D86zLOcuA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Hi again, still trying to understand how to make the setup to work.

As the very last thing I thought to check into /etc/sysconfig/authconfig.
What I found was that usekerberos and useldap were set to no. Maybe they
(or at least kerberos) need to be set to yes?

# cat /etc/sysconfig/authconfig
IPADOMAINJOINED=no
USEMKHOMEDIR=yes
USEPAMACCESS=no
CACHECREDENTIALS=yes
USESSSDAUTH=yes
USESHADOW=yes
USEWINBIND=no
USEDB=no
FORCELEGACY=no
USEFPRINTD=no
USEHESIOD=no
FORCESMARTCARD=no
PASSWDALGORITHM=sha512
USELDAPAUTH=no
IPAV2NONTP=no
USELOCAUTHORIZE=yes
USEECRYPTFS=no
USEIPAV2=no
USEWINBINDAUTH=no
USESMARTCARD=no
USELDAP=no
USENIS=no
USEKERBEROS=no
USESYSNETAUTH=no
USESSSD=yes
USEPWQUALITY=yes
USEPASSWDQC=no


On 24 October 2013 15:02, Roberts Klotiņš <roberts.klotins@gmail.com> wrote:

> Sorry to trouble again with this. but I thought it might be relevant to
> look through pam modules;
>
> I found sss present as per system installation; I have not modified the
> file
>
> # cat /etc/pam.d/password-auth
> #%PAM-1.0
> # This file is auto-generated.
> # User changes will be destroyed the next time authconfig is run.
> auth        required      pam_env.so
> auth        sufficient    pam_unix.so nullok try_first_pass
> auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
> auth        sufficient    pam_sss.so use_first_pass
> auth        required      pam_deny.so
>
> account     required      pam_unix.so broken_shadow
> account     sufficient    pam_localuser.so
> account     sufficient    pam_succeed_if.so uid < 1000 quiet
> account     [default=bad success=ok user_unknown=ignore] pam_sss.so
> account     required      pam_permit.so
>
> password    requisite     pam_pwquality.so try_first_pass retry=3
> authtok_type=
> password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass
> use_authtok
> password    sufficient    pam_sss.so use_authtok
> password    required      pam_deny.so
>
> session     optional      pam_keyinit.so revoke
> session     required      pam_limits.so
> -session     optional      pam_systemd.so
> session     optional      pam_oddjob_mkhomedir.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
>
> And GDM password config file includes the above:
>
> # cat /etc/pam.d/gdm-password
> auth     [success=done ignore=ignore default=bad] pam_selinux_permit.so
> auth        substack      password-auth
> auth        optional      pam_gnome_keyring.so
> auth        include       postlogin
>
> account     required      pam_nologin.so
> account     include       password-auth
>
> password    include       password-auth
>
> session     required      pam_selinux.so close
> session     required      pam_loginuid.so
> session     optional      pam_console.so
> -session    optional    pam_ck_connector.so
> session     required      pam_selinux.so open
> session     optional      pam_keyinit.so force revoke
> session     required      pam_namespace.so
> session     include       password-auth
> session     optional      pam_gnome_keyring.so auto_start
> session     include       postlogin
>
> I don't know where to look further in troubleshooting domain logons. I
> kind of hope it is some obvious misconfiguration in my sssd.conf which I
> posted before. Many thanks for looking at this,
>
> Roberts
>
>
>
>
> On 24 October 2013 14:01, Roberts Klotiņš <roberts.klotins@gmail.com>wrote:
>
>> Hi Thanks a lot for looking into this.
>>
>> As you suspected - there is something that enterprise simple login added
>> into the config file file:
>>
>> [sssd]
>> services = nss, pam
>> config_file_version = 2
>> domains = PEOPLE
>>
>> [nss]
>> filter_users = root
>> filter_groups = root
>>
>> [pam]
>>
>> [domain/PEOPLE]
>> description = PEOPLE AD domain
>> id_provider = ad
>> auth_provider = ad
>> access_provider = ad
>> chpass_provider = ad
>>
>> ad_server = srv1.people.local
>> ad_hostname = client1.people.local
>> ad_domain = PEOPLE.LOCAL
>> case_sensitive = false
>>
>> enumerate = true
>> cache_credentials = true
>> simple_allow_users = usr1, usr2
>>
>> However when I deleted the last line in this file I got the same result.
>> /var/log/secure
>> datet:42:54 robbie gdm-password]: pam_unix(gdm-password:auth):
>> authentication failure; logname=(unknown) uid=0 euid=0 tty=:1 ruser
>> = rhost=  user=PEOPLE\usr2
>> datet:42:54 robbie gdm-password]: pam_sss(gdm-password:auth):
>> authentication failure; logname=(unknown) uid=0 euid=0 tty=:1 ruser=
>>  rhost= user=PEOPLE\usr2
>> datet:42:54 robbie gdm-password]: pam_sss(gdm-password:auth): received
>> for user PEOPLE\usr2: 6 (Permission denied)
>> datet:42:59 robbie gdm-password]: pam_unix(gdm-password:auth):
>> conversation failed
>> datet:42:59 robbie gdm-password]: pam_unix(gdm-password:auth): auth could
>> not identify password for [PEOPLE\usr2]
>> datet:42:59 robbie gdm-password]: pam_sss(gdm-password:auth):
>> authentication failure; logname=(unknown) uid=0 euid=0 tty=:1 ruser=
>>  rhost= user=PEOPLE\usr2
>> datet:42:59 robbie gdm-password]: pam_sss(gdm-password:auth): received
>> for user PEOPLE\usr2: 7 (Authentication failure)
>>
>> It appears I may need to configure something in pam, but maybe that is
>> not the case??
>>
>> Your help is much appreciated.
>>
>> Roberts
>>
>>
>>
>>
>> On 24 October 2013 13:00, <sssd-users-request@lists.fedorahosted.org>wrote:
>>
>>> Send sssd-users mailing list submissions to
>>>         sssd-users@lists.fedorahosted.org
>>>
>>> To subscribe or unsubscribe via the World Wide Web, visit
>>>         https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>>> or, via email, send a message with subject or body 'help' to
>>>         sssd-users-request@lists.fedorahosted.org
>>>
>>> You can reach the person managing the list at
>>>         sssd-users-owner@lists.fedorahosted.org
>>>
>>> When replying, please edit your Subject line so it is more specific
>>> than "Re: Contents of sssd-users digest..."
>>>
>>>
>>> Today's Topics:
>>>
>>>    1.  GDM login (Roberts Klotiņš)
>>>    2. Re:  GDM login (Jakub Hrozek)
>>>
>>>
>>> ----------------------------------------------------------------------
>>>
>>> Message: 1
>>> Date: Thu, 24 Oct 2013 09:59:50 +0100
>>> From: Roberts Klotiņš <roberts.klotins@gmail.com>
>>> To: sssd-users@lists.fedorahosted.org
>>> Subject: [SSSD-users] GDM login
>>> Message-ID:
>>>         <
>>> CALr2nHs9s41VbMVECCLrUQx1mfJYgsQFcLAxzT-0QzudHuaW8g@mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hello,
>>>
>>> After 2 days of reading on Samba4 SSSD and AD login I am running into
>>> problems. I have set up
>>> - AD server with Samba 4.2  (CentOS 6.3) - domain PEOPLE.LOCAL
>>> - Fedora 19 machine
>>> - Windows XP machine joined the domain without problems, I can run
>>> dsa.msc successfully
>>>
>>> I want to achieve AD user login from gdm. I understand that I should
>>> create
>>> used with dsa.msc and then I don't know if I should add it through Fedora
>>> 19 user control panel. I tried it anyhow (was useful in debugging) but
>>> changes do not persist.
>>>
>>> I set up sssd (ver 1.11.1) it seems alright with AD options:
>>> - id and getent work for passwords and groups
>>>
>>> In my sssd.conf I have specified domain as [domain\PEOPLE]
>>> as all the correct server addresses etc are given there and it is easier
>>> to
>>> refer to the domain just by one name.
>>> sssd loads fine, getent passwd 'PEOPLE\user' works
>>>
>>> - realm discover gives this result
>>> realm discover  --verbose PEOPLE.LOCAL
>>>  * Resolving: _ldap._tcp.people.local
>>>  * Performing LDAP DSE lookup on: 192.168.1.74
>>>  ! Received invalid or unsupported Netlogon data from server
>>> people.local
>>>   type: kerberos
>>>   realm-name: PEOPLE.LOCAL
>>>   domain-name: people.local
>>>   configured: no
>>>
>>> I can add previously defined domain user via Settings - User : Enterprise
>>> with correct username and password, however this does not persist - if I
>>> close the user admin panel and then re-open it, the added user is gone.
>>>
>>> If I try to log on from GDM (user not listed so I use PEOPLE\user) I get
>>> authentication failure
>>> /var/log/secure gives these messages:
>>>
>>> date:00:19 host gdm-password]: pam_unix(gdm-password:auth):
>>> authentication
>>> failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost=
>>> user=PEOPLE\usr1
>>> date:00:19 host gdm-password]: pam_sss(gdm-password:auth): authentication
>>> failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost=
>>> user=PEOPLE\usr1
>>> date:00:19 host gdm-password]: pam_sss(gdm-password:auth): received for
>>> user PEOPLE\usr1: 6 (Permission denied)
>>> date:00:48 host gdm-password]: pam_unix(gdm-password:auth):
>>> authentication
>>> failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost=
>>> user=PEOPLE\usr1
>>> date:00:48 host gdm-password]: pam_sss(gdm-password:auth): authentication
>>> failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost=
>>> user=PEOPLE\usr1
>>> date:00:48 host gdm-password]: pam_sss(gdm-password:auth): received for
>>> user PEOPLE\usr1: 6 (Permission denied)
>>> date:01:40 host gdm-password]: pam_unix(gdm-password:auth):
>>> authentication
>>> failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost=
>>> user=PEOPLE\usr2
>>> date:01:40 host gdm-password]: pam_sss(gdm-password:auth): authentication
>>> failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost=
>>> user=PEOPLE\usr2
>>> date:01:40 host gdm-password]: pam_sss(gdm-password:auth): received for
>>> user PEOPLE\usr2: 6 (Permission denied)
>>> date:01:46 host gdm-password]: pam_unix(gdm-password:auth): conversation
>>> failed
>>> date:01:46 host gdm-password]: pam_unix(gdm-password:auth): auth could
>>> not
>>> identify password for [PEOPLE\usr2]
>>> date:01:46 host gdm-password]: pam_sss(gdm-password:auth): authentication
>>> failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost=
>>> user=PEOPLE\usr2
>>> date:01:46 host gdm-password]: pam_sss(gdm-password:auth): received for
>>> user PEOPLE\usr2: 7 (Authentication failure)
>>> date:01:46 host gdm-password]: gkr-pam: no password is available for user
>>>
>>> Could someone point me in the right direction as to what is wrong with my
>>> setup. I have sorted some problems out by myself, but here I feel out of
>>> depth.
>>>
>>> Many thanks,
>>>
>>> Roberts
>>> -------------- next part --------------
>>> An HTML attachment was scrubbed...
>>> URL: <
>>> https://lists.fedorahosted.org/pipermail/sssd-users/attachments/20131024/d09de109/attachment-0001.html
>>> >
>>>
>>> ------------------------------
>>>
>>> Message: 2
>>> Date: Thu, 24 Oct 2013 12:01:11 +0200
>>> From: Jakub Hrozek <jhrozek@redhat.com>
>>> To: sssd-users@lists.fedorahosted.org
>>> Subject: Re: [SSSD-users] GDM login
>>> Message-ID: <20131024100111.GD4240@hendrix.redhat.com>
>>> Content-Type: text/plain; charset=utf-8
>>>
>>> On Thu, Oct 24, 2013 at 09:59:50AM +0100, Roberts Klotiņš wrote:
>>> > Hello,
>>> >
>>> > After 2 days of reading on Samba4 SSSD and AD login I am running into
>>> > problems. I have set up
>>> > - AD server with Samba 4.2  (CentOS 6.3) - domain PEOPLE.LOCAL
>>> > - Fedora 19 machine
>>> > - Windows XP machine joined the domain without problems, I can run
>>> > dsa.msc successfully
>>> >
>>> > I want to achieve AD user login from gdm. I understand that I should
>>> create
>>> > used with dsa.msc and then I don't know if I should add it through
>>> Fedora
>>> > 19 user control panel. I tried it anyhow (was useful in debugging) but
>>> > changes do not persist.
>>> >
>>> > I set up sssd (ver 1.11.1) it seems alright with AD options:
>>> > - id and getent work for passwords and groups
>>> >
>>> > In my sssd.conf I have specified domain as [domain\PEOPLE]
>>> > as all the correct server addresses etc are given there and it is
>>> easier to
>>> > refer to the domain just by one name.
>>> > sssd loads fine, getent passwd 'PEOPLE\user' works
>>> >
>>> > - realm discover gives this result
>>> > realm discover  --verbose PEOPLE.LOCAL
>>> >  * Resolving: _ldap._tcp.people.local
>>> >  * Performing LDAP DSE lookup on: 192.168.1.74
>>> >  ! Received invalid or unsupported Netlogon data from server
>>> > people.local
>>>
>>>  ^^^ This is a Samba bug. I've seen it reported by another user, but I'm
>>>  not sure if it's reported to Samba upstream.
>>>
>>> >   type: kerberos
>>> >   realm-name: PEOPLE.LOCAL
>>> >   domain-name: people.local
>>> >   configured: no
>>> >
>>> > I can add previously defined domain user via Settings - User :
>>> Enterprise
>>> > with correct username and password, however this does not persist - if
>>> I
>>> > close the user admin panel and then re-open it, the added user is gone.
>>>
>>> This sounds like Enterprise Logins bug, but let's resolve the Permission
>>> Denied first.
>>>
>>> >
>>> > If I try to log on from GDM (user not listed so I use PEOPLE\user) I
>>> get
>>> > authentication failure
>>> > /var/log/secure gives these messages:
>>> >
>>> > date:00:19 host gdm-password]: pam_unix(gdm-password:auth):
>>> authentication
>>> > failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost=
>>> > user=PEOPLE\usr1
>>> > date:00:19 host gdm-password]: pam_sss(gdm-password:auth):
>>> authentication
>>> > failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost=
>>> > user=PEOPLE\usr1
>>> > date:00:19 host gdm-password]: pam_sss(gdm-password:auth): received for
>>> > user PEOPLE\usr1: 6 (Permission denied)
>>> > date:00:48 host gdm-password]: pam_unix(gdm-password:auth):
>>> authentication
>>> > failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost=
>>> > user=PEOPLE\usr1
>>> > date:00:48 host gdm-password]: pam_sss(gdm-password:auth):
>>> authentication
>>> > failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost=
>>> > user=PEOPLE\usr1
>>> > date:00:48 host gdm-password]: pam_sss(gdm-password:auth): received for
>>> > user PEOPLE\usr1: 6 (Permission denied)
>>> > date:01:40 host gdm-password]: pam_unix(gdm-password:auth):
>>> authentication
>>> > failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost=
>>> > user=PEOPLE\usr2
>>> > date:01:40 host gdm-password]: pam_sss(gdm-password:auth):
>>> authentication
>>> > failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost=
>>> > user=PEOPLE\usr2
>>> > date:01:40 host gdm-password]: pam_sss(gdm-password:auth): received for
>>> > user PEOPLE\usr2: 6 (Permission denied)
>>> > date:01:46 host gdm-password]: pam_unix(gdm-password:auth):
>>> conversation
>>> > failed
>>> > date:01:46 host gdm-password]: pam_unix(gdm-password:auth): auth could
>>> not
>>> > identify password for [PEOPLE\usr2]
>>> > date:01:46 host gdm-password]: pam_sss(gdm-password:auth):
>>> authentication
>>> > failure; logname=(unknown) uid=0 euid=0 tty=:0 ruser= rhost=
>>> > user=PEOPLE\usr2
>>> > date:01:46 host gdm-password]: pam_sss(gdm-password:auth): received for
>>> > user PEOPLE\usr2: 7 (Authentication failure)
>>> > date:01:46 host gdm-password]: gkr-pam: no password is available for
>>> user
>>> >
>>> > Could someone point me in the right direction as to what is wrong with
>>> my
>>> > setup. I have sorted some problems out by myself, but here I feel out
>>> of
>>> > depth.
>>> >
>>> > Many thanks,
>>> >
>>> > Roberts
>>>
>>> Can you attach your sssd.conf? I suspect that realmd/enterprise logins
>>> set up the simple access provider and the user is not included in the
>>>
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> sssd-users mailing list
>>> sssd-users@lists.fedorahosted.org
>>> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>>>
>>>
>>> End of sssd-users Digest, Vol 18, Issue 25
>>> ******************************************
>>>
>>
>>
>>
>> --
>> ==
>> Roberts Klotins
>>
>>
>
>
> --
> ==
> Roberts Klotins
>
>


--
==
Roberts Klotins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-users/attachments/20131025/c926d883/attachment.html>

------------------------------

_______________________________________________
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users


End of sssd-users Digest, Vol 18, Issue 27
******************************************



--
==
Roberts Klotins