attachment
sssd_Mydomain.log

attachment
sssd.conf

attachment
krb5.conf

Thanks for the bug report, this sounds a lot like ticket #2889. There should be a workaround of setting ad_gpo_access_control = permissive in sssd.conf. But we still need to look into the logs..

Which version of sssd do you use on openSUSE 42.1.
IIRC there is sssd-1.11.5.1 which is quite buggy.

Or do you use sssd-1.13.x ?

Hello,
I use 1.13.1 from http://download.opensuse.org/repositories/spins:/invis:/stable/openSUSE_42.1/

Replying to [comment:3 ptulpen]:

Hello,
I use 1.13.1 from http://download.opensuse.org/repositories/spins:/invis:/stable/openSUSE_42.1/
I can see there is sssd-1.13.2-177.1.x86_64.rpm in that repo. But it probably would not work for you because GPO is enforcing mode by default since sssd-1.13.x and it is not changed on spec file.

But I can see more issues in your log file.
It might be related.

373:(Wed Dec  2 15:03:52 2015) [sssd[be[MYDOMAIN]]] [sss_write_krb5_localauth_snippet] (0x0040): creating the temp file [/var/lib/sss/pubconf/krb5.include.d/localauth_pluginrfbhoJ] for domain-realm mappings failed.
374:(Wed Dec  2 15:03:52 2015) [sssd[be[MYDOMAIN]]] [sss_write_krb5_localauth_snippet] (0x0080): Could not remove file [/var/lib/sss/pubconf/krb5.include.d/localauth_pluginrfbhoJ]: [2]: No such file or directory
375:(Wed Dec  2 15:03:52 2015) [sssd[be[MYDOMAIN]]] [sss_write_krb5_conf_snippet] (0x0040): sss_write_krb5_localauth_snippet failed.
376:(Wed Dec  2 15:03:52 2015) [sssd[be[MYDOMAIN]]] [ad_subdom_reinit] (0x0080): sss_write_krb5_conf_snippet failed.
388:(Wed Dec  2 15:03:52 2015) [sssd[be[MYDOMAIN]]] [sss_write_domain_mappings] (0x0040): creating the temp file [/var/lib/sss/pubconf/krb5.include.d/domain_realm_MYDOMAINea1FxF] for domain-realm mappings failed.
389:(Wed Dec  2 15:03:52 2015) [sssd[be[MYDOMAIN]]] [sss_write_domain_mappings] (0x0080): Could not remove file [/var/lib/sss/pubconf/krb5.include.d/domain_realm_MYDOMAIN�]: [2]: No such file or directory

sssd was not able to create domain-realm mappings because the directory /var/lib/sss/pubconf/krb5.include.d does not exist. It exist on fedora and it's owned bt package sssd-ipa.

[root@host ~]# rpm -qf /var/lib/sss/pubconf/krb5.include.d/
sssd-ipa-1.13.2-1.fc23.x86_64
[root@host ~]# ls -ld /var/lib/sss/pubconf/krb5.include.d/
drwxr-xr-x. 2 root root 4096 Nov 10 13:27 /var/lib/sss/pubconf/krb5.include.d/

But I also have include n krb5.conf

includedir /var/lib/sss/pubconf/krb5.include.d/

It might explain why we was not able to find data about forest.

[ad_master_domain_netlogon_done] (0x0080): No netlogon data available. Flat name might not be usable
[ad_subdomains_master_dom_done] (0x0400): SSSD needs to look up the forest root domain
[sdap_print_server] (0x2000): Searching 10.16.0.3
[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=trustedDomain)(trustType=2)(!(msDS-TrustForestTrustInfo=*))(cn=(null)))][DC=MYDOMAIN,DC=net].
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [flatName]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [trustPartner]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [securityIdentifier]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [trustType]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [trustAttributes]
[sdap_get_generic_ext_step] (0x0080): ldap_search_ext failed: Bad search filter
[generic_ext_search_handler] (0x0040): sdap_get_generic_ext_recv failed [1432158239]: Malformed search filter

The forest is null in ldap search

But all this things might unrelated if you not not want to use users form trusted ADs

The main problem is that sssd was not able to find "service login maps" in GPO access control

[sdap_account_expired_ad] (0x0400): Performing AD access check for user [myuser]
[sdap_account_expired_ad] (0x4000): User account control for user [myuser] is [200].
[sdap_account_expired_ad] (0x4000): Expiration time for user [myuser] is [0].

[ad_gpo_access_send] (0x0400): service login maps to Interactive
[sdap_id_op_connect_step] (0x4000): reusing cached connection
[ad_gpo_connect_done] (0x4000): server_hostname from uri: mydc.MYDOMAIN.NET
[ad_gpo_connect_done] (0x0400): sam_account_name is myclient$
[sdap_print_server] (0x2000): Searching 10.16.0.3

[sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectclass=user)(sAMAccountName=myclient$))][dc=MYDOMAIN].
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [distinguishedName]
[sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userAccountControl]
[sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
[sdap_get_generic_op_finished] (0x0400): Search result: Referral(10), 0000202B: RefErr: DSID-031007EF, data 0, 1 access points

[sdap_get_generic_ext_add_references] (0x1000): Additional References: ldap://MYDOMAIN/dc=MYDOMAIN
[sdap_op_destructor] (0x2000): Operation 16 finished
[generic_ext_search_handler] (0x4000): Request included referrals which were ignored.
[generic_ext_search_handler] (0x4000):     Ref: ldap://MYDOMAIN/dc=MYDOMAIN
[ad_gpo_target_dn_retrieval_done] (0x0040): No DN retrieved for policy target.
[sdap_id_op_destroy] (0x4000): releasing operation connection
[ad_gpo_access_done] (0x0040): GPO-based access control failed.

[be_pam_handler_callback] (0x0100): Backend returned: (3, 4, No such file or directory) [Internal Error (System error)]
[be_pam_handler_callback] (0x0100): Sending result [4][MYDOMAIN]

The problems with retrieving referrals might be related to issues in comment:4.

If you want to use GPO access control then it would be good to fix krb5-realm mappings issues.

If you d not want to use it. You can disable it (or use it in permissive mode). You can still use simple access-control provider. (man sssd-simple)

Fields changed

cc: => lslebodn@redhat.com

I would say the two might be related -- if we can't find the forest root, then chances are we can't discover the whole forest and then we're unable to follow the referral. And following referrals should be supported since we fixed https://fedorahosted.org/sssd/ticket/2645

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13.4
owner: somebody => pcech

Hello, we have no ipa nor a trusted domain, we use jsut the one doamin where all users and computers are stores.
Also we have currently no need for GPOs,so the permissive mode is perfectly fine for me.
But i jsut added the directory and attached the logfile.
just for mmy understanding: what do I need the "domain-realm mappings" and "service login maps" for?
I still have issues login in via Kerberos from by windows machines, might this be related?

Replying to [comment:9 ptulpen]:

Hello, we have no ipa nor a trusted domain, we use jsut the one doamin where all users and computers are stores.
Also we have currently no need for GPOs,so the permissive mode is perfectly fine for me.
But i jsut added the directory and attached the logfile.
just for mmy understanding: what do I need the "domain-realm mappings"
just create directory: /var/lib/sss/pubconf/krb5.include.d/ and add following line to krb5.conf
@see comment 4

includedir /var/lib/sss/pubconf/krb5.include.d/

and "service login maps" for?
I still have issues login in via Kerberos from by windows machines, might this be related?
maybe
If it does not work with gpo in permissive mode then
please follow instructions on wiki https://fedorahosted.org/sssd/wiki/Troubleshooting#TroubleshootingUserInformation

I added it and now have the log attached.
loggin in via ssh using username/pw now works including renew of tickets.
what not works is loggin in via putty (not sure if this is related or something I should create a new ticekt for)

when I login via kerberos/putty, the login iself works, but I get no ticket and so cannot enter home directory

attachment
sssd_MYDOMAIN_15_dec.log

attachment

Replying to [comment:11 ptulpen]:

I added it and now have the log attached.
loggin in via ssh using username/pw now works including renew of tickets.
I'm glad that issue with GPO is fixed.

what not works is loggin in via putty (not sure if this is related or something I should create a new ticekt for)

It should work with password authentication.

when I login via kerberos/putty, the login iself works, but I get no ticket and so cannot enter home directory

You should configure forwarding (delegation) of GSSAPI credentials. Because you bypass sssd authentication with krb5 ticket and therefore sssd could not create ticket on the server.

You should configure your putty with equivalent to ssh -K

Hello,
I configured sshd with tis 2 parameters:
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

But this still does not work.

Before this just switched off Kerberos to let sssd take care of the ticekts and the renewal
So you suggest me to kets sshd create the ticket and use sssd "only" for authentication.
Do I then have to take care of renewal by mysself? (e.g. via krenew?)

sssd has an ability to renew a krb5 ticket. But it's unrelated to this ticket. You are able to login with sssd (GPO related denial was resolved). I would suggest to write a mail to sssd-users@lists.fedorahosted.org. If you describe your use-case someone can help you to find a solution either with sssd or other way.

owner: pcech => lslebodn

Fields changed

resolution: => worksforme
status: new => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3932

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.