[SSSD-users] login with shortname in AD cross realm

Longina Przybyszewska longina at sdu.dk
Thu Jan 22 22:42:11 UTC 2015



Mange hilsner
Longina


> -----Original Message-----
> From: sssd-users-bounces at lists.fedorahosted.org [mailto:sssd-users-
> bounces at lists.fedorahosted.org] On Behalf Of Jakub Hrozek
> Sent: 21. januar 2015 21:08
> To: sssd-users at lists.fedorahosted.org
> Subject: Re: [SSSD-users] login with shortname in AD cross realm
> 
> On Wed, Jan 21, 2015 at 01:07:00PM +0000, Longina Przybyszewska wrote:
> >
> > > -----Original Message-----
> > > From: sssd-users-bounces at lists.fedorahosted.org [mailto:sssd-users-
> > > bounces at lists.fedorahosted.org] On Behalf Of Jakub Hrozek
> > > Sent: 21. januar 2015 13:49
> > > To: sssd-users at lists.fedorahosted.org
> > > Subject: Re: [SSSD-users] login with shortname in AD cross realm
> > >
> > > On Wed, Jan 21, 2015 at 12:26:33PM +0000, Longina Przybyszewska
> wrote:
> > > > Hi,
> > > > Is it possible to configure SSSD to make  possible to  login with
> > > > short names
> > > across trusty domains?
> > > > The sAMAccount name attribute in AD  are unique, and all users
> > > > have Posix
> > > attributes assigned so there is no risk for name  mismatch between
> > > different domains.
> > > >
> > > > I use ad provider and all  default setting for AD
> > > > backend(gc_search_enable) ;
> > > >
> > > > If use_fully_qualified_names = False only users from client
> > > > machines native
> > > domain can login with shortnames; Users from other domains are
> > > "unknown".
> > > >
> > > > I can successfully make ldapsearch to Global Catalog in top domain
> > > > for  login
> > > names=shortname for users from different domains:
> > > >
> > > > ldapsearch -H ldap://ldap.c.example.com:3268 -Y GSSAPI -N -b
> > > "dc=c,dc=example,dc=org"
> > > "(&(objectClass=user)(sAMAccountName=user))"
> > > > user = user-a from a.c.example.org user = user-b from
> > > > b.c.example.org
> > > >
> > > > best,
> > > > Longina
> > > >
> > >
> > > Only using the default_domain_suffix option, but then you need to
> > > qualify the primary domain IIRC..
> >
> > You mean,, I have to have on all machines default-domain_suffix =
> c.example.org.
> 
> Yes.
> 
> >
> > I am not sure that I understand the "qualify the primary domain IIRC" del...
> 
> What I meant is if you had the main domain called example.com, subdomain
> called c.example.com and set the suffix to c.example.com, then retrieving
> users from the main domain would require appending the domain
> name:
>     getent passwd administrator at example.com But subdomain users could be
> un-qualified
>     getent passwd some_user_from_subdomain
> 
> Also, I wonder if using the fully qualified name, or the netbios name is really a
> problem? After all, that's how it's done in Windows..
> > >
> > If client machines and servers were in  c.example.org natively, user left in
> subdomains -would it help?
> 
> Not sure I understand, but if all users are in subdomains, then using
> default_domain_suffix makes sense.

Yes, all users are in subdomains, but there are also users in top domain c.example.org.

I traced NFS4 idmaping problem to ' nss_getpwname' call ;
Idmapd on the NFS server can  so far resolve only unqualified names  local for its domain  ;

I would like to be able to resolve 'nss_getpwname' call for userA (from A.C.EXAMPLE.ORG), and userB (from B.C.EXAMPLE.ORG)
and for userC (from C.EXAMPLE.ORG) with their respectively unqualified names on the NFS server;

Setup could  be  more simple  if server and client machines  join C.EXAMPLE.ORG:
Users from C.EXAMPLE.COM are in local domain;
Users from subdomains can login unqualified via default_domain _suffix = c.example.org;


Best,
longina


More information about the sssd-users mailing list