I agree that this sounds like, and indeed is, a recipe for disaster. I was
going to explain some of the woes of our environment but I don't think
it's
actually relevant after looking at my problem a bit more. If I'm way off
base I'm happy to be herded back, but please tolerate me as I share what I
am seeing today because I really hope to solve the narrow issue of SMB file
access without delving too far into the proper long-term fixes we require.
I can see now that authentication works fine and I can access shares on the
local filesystem. What seems to be failing is the mount performed by
gssproxy when trying to access a share. The NFS server isn't kerberized so
the Samba server should be mounting everything with the sys mount option,
but gssproxy appears to only perform mounts with krb5. When I try to
access even an already-mounted NFS directory to which I have permission,
gssproxy complains:
Jul 10 08:55:51 smb gssproxy: gssproxy[1469]: (OID: { 1 2 840 113554 1 2 2
}) Unspecified GSS failure. Minor code may provide more information,
Client 'host/smb.soe.ucsc.edu at AD.SOE.UCSC.EDU' not found in Kerberos
database
We have an existing Samba 4.8.3 server that is configured to use the ldap
backend and does not run winbind, which gives us the desired behavior. I
was hoping to replace that server because it has its own issues, but with
the ad backend since the ldap one is no longer recommended. gssproxy's man
page indicates that it cannot be configured to mount otherwise. Am I out
of luck with winbind?
On Tue, Jul 9, 2019 at 12:08 PM Rowland penny via samba <
samba at lists.samba.org> wrote:
> On 09/07/2019 20:00, Eric Shell wrote:
> > Hi Rowland,
> >
> > Currently Domain Users doesn't have a gidNumber because it
didn't have
> > a corresponding group in OpenLDAP, which is our master directory.
> Did you miss the bit where I said Domain Users MUST have a gidNumber ?
> >
> > The primary Unix group gidNumber for each user is replicated from
> > their OpenLDAP records, but the AD groups have a suffix due to
> > historical name collisions - a POSIX group called harry would be
> > harry-group in AD, but with a matching gidNumber.
>
> That sounds like a recipe for disaster, but then again, if it works for
> you, however it sounds like it doesn't ;-)
>
> What do you use the openldap server for ?
>
> Could you move whatever it is to the Samba AD ?
>
> Rowland
>
>
> >
> > On Tue, Jul 9, 2019 at 11:53 AM Rowland penny via samba
> > <samba at lists.samba.org <mailto:samba at
lists.samba.org>> wrote:
> >
> > On 09/07/2019 19:46, Eric Shell via samba wrote:
> > > Hi Rowland,
> > >
> > > Thanks for the prompt reply. The gidNumber attribute is set
to the
> > > appropriate primary UNIX group for each user already. Are
there
> > any ways
> > > to work around the ID issue, or at least to mitigate some of
the
> > > consequences? We looked at updating uid/gid values across
the
> > board but
> > > there is so much data owned by existing users and groups that
we
> > haven't
> > > been able to proceed.
> >
> > I sort of thought that would be the case.
> >
> > Does Domain Users have a gidNumber ?
> >
> > You say 'appropriate primary Unix group', are these groups
in AD
> > and how
> > are they named ?
> >
> > Rowland
> >
> >
> >
> > --
> > To unsubscribe from this list go to the following URL and read the
> > instructions: https://lists.samba.org/mailman/options/samba
> >
> >
> >
> > --
> > Eric Shell
> > BSOE Technical Staff
> > eshell at ucsc.edu <mailto:eshell at ucsc.edu>
> > 831 459 4919
> > Baskin Engineering, Room 313
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions: https://lists.samba.org/mailman/options/samba
>
--
Eric Shell
BSOE Technical Staff
eshell at ucsc.edu
831 459 4919
Baskin Engineering, Room 313
On 10/07/2019 17:20, Eric Shell via samba wrote:> I agree that this sounds like, and indeed is, a recipe for disaster. I was > going to explain some of the woes of our environment but I don't think it's > actually relevant after looking at my problem a bit more. If I'm way off > base I'm happy to be herded back, but please tolerate me as I share what I > am seeing today because I really hope to solve the narrow issue of SMB file > access without delving too far into the proper long-term fixes we require. > > I can see now that authentication works fine and I can access shares on the > local filesystem. What seems to be failing is the mount performed by > gssproxy when trying to access a share. The NFS server isn't kerberized so > the Samba server should be mounting everything with the sys mount option, > but gssproxy appears to only perform mounts with krb5. When I try to > access even an already-mounted NFS directory to which I have permission, > gssproxy complains: > > Jul 10 08:55:51 smb gssproxy: gssproxy[1469]: (OID: { 1 2 840 113554 1 2 2 > }) Unspecified GSS failure. Minor code may provide more information, > Client 'host/smb.soe.ucsc.edu at AD.SOE.UCSC.EDU' not found in Kerberos > databaseIt would complain, GSS is a kerberos thing, so you need a ticket for it. Can you kerberise NFS ?> We have an existing Samba 4.8.3 server that is configured to use the ldap > backend and does not run winbind, which gives us the desired behavior. I > was hoping to replace that server because it has its own issues, but with > the ad backend since the ldap one is no longer recommended. gssproxy's man > page indicates that it cannot be configured to mount otherwise. Am I out > of luck with winbind?So, it isn't an AD domain member, if it was, you would have to run winbind. I think I have asked this twice already, but you never know, third time lucky ;-) What do you use the openldap server for ? Could you use an AD DC instead ? Rowland
> > When I try to > > access even an already-mounted NFS directory to which I have permission, > > gssproxy complains: > > > > Jul 10 08:55:51 smb gssproxy: gssproxy[1469]: (OID: { 1 2 840 113554 1 2 > 2 > > }) Unspecified GSS failure. Minor code may provide more information, > > Client 'host/smb.soe.ucsc.edu at AD.SOE.UCSC.EDU' not found in Kerberos > > database > > It would complain, GSS is a kerberos thing, so you need a ticket for it. > > Can you kerberise NFS ? >Kerberizing NFS is something we've wanted to do for a while as a way out of our low ID issue but wasn't ever implemented. We may be forced to do it now.> > We have an existing Samba 4.8.3 server that is configured to use the ldap > > backend and does not run winbind, which gives us the desired behavior. I > > was hoping to replace that server because it has its own issues, but with > > the ad backend since the ldap one is no longer recommended. gssproxy's > man > > page indicates that it cannot be configured to mount otherwise. Am I out > > of luck with winbind? > So, it isn't an AD domain member, if it was, you would have to run winbind. >No, the old server isn't a member. It only uses AD for authentication. Please see the bottom of this message for that server's smb.conf file. It's a real Frankenstein's monster which began as a Samba 3 configuration and has been touched by many hands since then, but it more or less does its job. Maybe I should focus on recreating this configuration instead of using the ad backend, despite the ldap one being deprecated?> I think I have asked this twice already, but you never know, third time > lucky ;-) > > What do you use the openldap server for ? >I'm sorry, I thought I had answered this. It is used to provide authentication and user information services to various Unix systems and web services. It's still in place largely due to legacy reasons.> Could you use an AD DC instead ? >Similar to Kerberizing NFS, this was also a plan that was backburnered for a long while. -- [global] workgroup = BSOE server string = SAMBA-01 netbios name = SAMBA-01 realm = ad.soe.ucsc.edu security = ads winbind nss info = template logging = syslog at 2 log level = 2 browseable = yes read only = no local master = no load printers = no preserve case = yes case sensitive = yes wins support = no passdb backend = tdbsam printing = bsd printcap name = /dev/null disable spoolss = yes client ldap sasl wrapping = sign short preserve case = yes nt acl support = no wide links = no unix extensions = no strict locking = yes kernel change notify = no idmap config * : backend = ldap idmap config * : range = 100-999999999 idmap config * : ldap_url = ldaps://ldap-01.soe.ucsc.edu/ idmap config * : ldap_base_dn = dc=soe,dc=ucsc,dc=edu -- Eric Shell BSOE Technical Staff eshell at ucsc.edu 831 459 4919 Baskin Engineering, Room 313