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