-----Oprindelig meddelelse-----
Fra: Lukas Slebodnik [mailto:lslebodn@redhat.com]
Sendt: 8. januar 2016 12:15
Til: End-user discussions about the System Security Services Daemon
Emne: [SSSD-users] Re: localauth plugin and some other questions
On (08/01/16 11:23), Sumit Bose wrote:
>On Wed, Jan 06, 2016 at 01:11:50PM +0000, Longina Przybyszewska wrote:
>>
>> Thank you for the answers.
>> There are still some issues:
>>
>>
>> > > 2.
>> > > I tried login with setup for UPN/sAMAccountName login- without
success.
>> > > Is login with cross realm's UPN or short sAMAccoutName
supported
in this
>> > sssd version?
>> > >
>> > > In database for default domain cache_a.c.realm.db user object
>> > > has
>> > following names (for 'use_fully_qualified_names = true' setup):
>> > >
>> > > dn: name = user1(a)n.c.realm ...
>> > > name: user1(a)n.c.realm
>> > > nameAlias. user1(a)n.c.realm
>> > > UserPrincipalName: user1@REALM
>> > > canonicalUserPrincipalName: user1(a)N.C.REALM
>> >
>> > The plain sAMAccoutName 'user1' will not work because
>> > use_fully_qualified_names = true. What should work is 'DOM\user1'
>> > where DOM is the NetBIOS domain name of n.c.realm domain.
>> > Additionally I would expect that user1@REALM should work.
>> >
>>
>> Right. user1(a)n.c.realm and DOM\user1 login works.
>>
>> Login as user1@REALM (and user1@realm) does not work.
>
>hm, that's odd, can you send me the logs when trying to login with
>user1@REALM?
>
>>
>> getent passwd user1@realm
>> user1@n.c.realm@a.c.realm:*:10002:30000000::/home/user1:/bin/bash
>
>'user1@n.c.realm(a)a.c.realm' looks odd, do you map the user name to an
>attribute other than sAMAccoutName?
>
>>
>> The best would be able to login with sAMAccountName; The next best
>> with upn, then with fqdn.
>>
>> I tried without success the following setup for login with short names :
>> [nss]
>> subdomain_inherit = ldap_user_principal
>>
>> [domain/..]
>> ..
>> ldap_user_principal = sAMAccountName
>
>this won't work because ldap_user_principal value is used as a Kerberos
>principal without further processing.
>
>You might want to try the 'default_domain_suffix' option, see man
>sssd.conf for details.
>
>>
>>
>> > > 3.
>> > > Localauth plugin:
>> > > the option :
>> > > krb5_confd_path = /var/lib/sss/pubconf/krb5.conf.d
>> > >
>> > > -does not create that directory (I understand from the doc that
>> > > sssd should take care about it);
>> >
>> > no, SSSD expects the directory to be present, it should be create
>> > during the package installation.
>> >
>> This is the content of /var/lib/sss/pubconf :
>>
>> ls /var/lib/sss/pubconf/
>> kdcinfo A.C.REALM krb5.conf.d krb5.include.d
>>
>> 'krb5.conf.d' I have created manually ; After removing everything in
>> /var/lib/sss/{db,mc,pubconf}/* and restarting sssd 'krb5.include.d'
disappeared.
>
>yes, as said, SSSD does not create the directory for the krb5 config
>snippets.
>
>>
>> >
>> > > [sssd[be[a.c.realm]]] [sss_write_domain_mappings] (0x0200):
>> > > Mapping file for domain [a.c.realm] is
>> > > [/var/lib/sss/pubconf/krb5.include.d/domain_realm_a_c_realm]
>> > > [sssd[be[a.c.realm]]] [sss_write_domain_mappings] (0x0040):
>> > > creating the
>> > temp file
>> > [/var/lib/sss/pubconf/krb5.include.d/domain_realm_a_c_realmU4PYcJ]
>> > for domain-realm mappings failed.
>> > > [sssd[be[a.c.realm]]] [sss_write_domain_mappings] (0x0080): Could
>> > > not remove file
>> >
[/var/lib/sss/pubconf/krb5.include.d/domain_realm_a_c_realmU4P<B0>]:
>> > [2]: No such file or directory ....
>> > > ls -ld
>> > > drwxr-xr-x 2 root root 4096 Dec 16 16:08
>> > > /var/lib/sss/pubconf/krb5.conf.d/
>> >
>> > It looks SSSD still tries the default location, did you put
>> > krb5_confd_path in the right [domain/..] section?
>> >
>>
>> Yes.
>> ...
>> [domain/a.c.realm]
>> ...
>> krb5_confd_path = /var/lib/sss/pubconf/krb5.conf.d
Why do you want to use different directory?
I think it was suggested name - in one of previous sssd versions - but not sure now.
Why it cannot be standard directory
/var/lib/sss/pubconf/krb5.include.d ?
This directory is owned by sssd-krb5-common on debian (sssd-1.13.3)
it shoudl be allowed in apparmor to write to this directory
profile /usr/lib/@{multiarch}/sssd/* {
/var/lib/sss/pubconf/krb5.include.d/ rw,
}
But it needn't be allowed to write into
your custom directory /var/lib/sss/pubconf/krb5.conf.d
I changed the krb5_confd_path = /var/lib/sss/pubconf/krb5.include.d and the
localauth snippet is written to it.
It is allowed in apparmor in Ubuntu sssd-13.2 - as you have written.
Thank you.
Longina
> LS
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/admin/lists/sssd-
> users(a)lists.fedorahosted.org