Rowland Penny
2023-Feb-09 20:38 UTC
[Samba] After Suse Enterprise upgrade from 11.4 to 15.4 PCs fails authentication when trying to mount Samba share
On 09/02/2023 20:00, John Adamski (Work Account) wrote:> Thanks for the reply. I have a question or two to clarify what you stated. > > First the ranges in the idmap settings was what the SUSE tech that had the case suggested. I just left them large after they closed the case. I will try setting them back to normal range.The problem is, if you change the ranges, you change file ownership, so by that guy changing them, they changed file ownership if any new files have been created.> > Second the password server line has been include and excluded on different tries, I think was left in from last things the SUSE tech had me try. I will comment out and see if that helps. > > Now to my clarification question(s): > > I don't understand these comments: > >> idmap config GRACELAND:unix_nss_info = yes > > Only used with the 'ad' idmap backend > >> idmap config GRACELAND : backend = tdb > > Here is the biggy, the 'tdb' idmap shouldn't be used for the main domain, you should be using 'ad', 'rid', 'autorid' or 'nss' idmap backends > > I am not sure which config lines you are talking about and what they should be instead. Can you clarify? >There are various idmap backends: You can read the documentation for each backend by entering 'man idmap-BACKEND' where 'BACKEND' can be: tdb ad rid autorid nss NOTE: there are others, but they are the main ones used. tdb: This an allocating backend and is used for the default domain '*' ad: This requires that users are given a UidNumber attribute containing a unique number in the DOMAIN range, Domain Users must also have a gidNumber attribute. Any group that you require to be visible to Unix must also have a gidNumber attribute. You can also use the other RFC2307 attributes rid: This calculates the Unix user and group ID's from the user or group RID using the low DOMAIN range set in smb.conf autorid: works similar to 'rid' but is used for multiple domains. nss: requires local users and groups to match AD user and groups NOTE: 'DOMAIN' above refers to the worgroup name. The 'idmap config' lines that I referred to only have relevance if you use the 'ad' idmap backend You said: The ERP requires local Linux user accounts and local group for security so can't get this from AD. I don't know if you noticed my reply: Yes you can Properly set up, Samba makes AD users into local users. If you accept that the output from 'getent passwd A_USERNAME' shows local users, then: getent passwd rowland rowland:*:11104:10513:Rowland Penny:/home/rowland:/bin/bash Means that 'rowland is a local user, right ? Then what do you make of this: rowland at devstation:~$ grep 'rowland' /etc/passwd rowland at devstation:~$ Rowland is not in /etc/passwd And rowland at devstation:~$ wbinfo -u | grep rowland rowland wbinfo reads from AD, so 'rowland' only exists in AD, but is a local Unix user. Any further questions etc, please ask. Rowland
John Adamski (Work Account)
2023-Feb-10 18:22 UTC
[Samba] After Suse Enterprise upgrade from 11.4 to 15.4 PCs fails authentication when trying to mount Samba share
Rowland,
Thanks for the information, not sure I get it all. Samba never been my thing so
never tried to learn all there is.
I went back to a pre-upgrade backup copy of the smb.conf file as I was sure we
didn't us the idmap and that was what the SUSE tech changed the config file
to use. We used ldap mostly in the past (SLES 11.4).
***pre-upgrade***
Smbd --version
Version 3.6.3-94.34.1-3868-SUSE-CODE11-x86_64
Smb.conf (only global section)
[global]
workgroup = GRACELAND
passdb backend = ldapsam:ldap://xxxxxx.graceland.edu
map to guest = Bad User
logon path = \\%L\profiles\.msprofile
logon home = \\%L\%U\.9xprofile
logon drive = P:
usershare allow guests = No
netbios name = xxxxxx
wins support = No
server string = Samba Server
log file = /var/log/samba/log.%m
max log size = 1000
ldap admin dn = CN=xxxxxx,CN=Users,DC=graceland,DC=edu
ldap group suffix = ou=Groups
ldap idmap suffix = ou=Idmap
ldap machine suffix = ou=Machines
ldap passwd sync = Yes
ldap ssl = Off
ldap suffix = dc=xxxxxx,dc=graceland,dc=edu
ldap user suffix = ou=Users
security = ADS
realm = GRACELAND.EDU
allow insecure wide links = yes
client ipc signing = auto
max protocol = smb2
wins server
*** current production server ***
smbd --version
Version 4.15.8-git.527.8d0c05d313e150400.3.16.11-SUSE-oS15.0-x86_64 (our
test/dev server on Version 4.15.13-git.591)
Smb.conf (only global section)
[global]
workgroup = GRACELAND
realm = GRACELAND.EDU
security = ADS
netbios name = xxxxxx
log level = 10
usershare allow guests = No
wins support = No
idmap config * : backend = tdb
idmap config * : range = 10000-199999
idmap config GRACELAND:unix_nss_info = yes
idmap config GRACELAND : backend = tdb
idmap config GRACELAND : base_rid = 0
idmap config GRACELAND : range = 10000-199999
allow insecure wide links = yes
client ipc signing = auto
wins server winbind use default domain = true
I'm more familiar with ldap, and the SUSE tech didn't seem to like it or
want to debug why the old config didn't work on the newer version. Hench the
major rewrite of the smb.conf file. Would it be better to keep plowing ahead
with the current config using idmap or going back to ldap and figuring out why
ldap stopped working with the upgrade?
The problem I had right after upgrading was when I tried to join the server to
the domain and that what I originally opened the call with SUSE about. Since I
couldn't get the server on the domain samba didn't work. I was thinking
it was a Samba/Kerberos config problem, but SUSE went on their own direction.
This is the error when trying to join the domain {I'm using the test/dev
right now}
net ads join -U administrator
Password for [GRACELAND\administrator]:
fetch_ldap_pw: neither ldap secret retrieved!
pdb_init_ldapsam_common: Failed to retrieve LDAP password from secrets.tdb
pdb backend ldapsam:ldap://dc02.graceland.edu did not correctly init (error was
NT_STATUS_NO_MEMORY)
==============================================================INTERNAL ERROR:
pdb_get_methods: failed to get pdb methods for backend
ldapsam:ldap://xxxxxx.graceland.edu
in pid 10389 (4.15.13-git.591.ab36624310c150400.3.19.1-SUSE-oS15.0-x86_64)
If you are running a recent Samba version, and if you think this problem is not
yet fixed in the latest versions, please consider reporting this bug, see
https://wiki.samba.org/index.php/Bug_Reporting
==============================================================PANIC (pid 10389):
pdb_get_methods: failed to get pdb methods for backend
ldapsam:ldap://xxxxxx.graceland.edu
in 4.15.13-git.591.ab36624310c150400.3.19.1-SUSE-oS15.0-x86_64
BACKTRACE: 12 stack frames:
#0 /usr/lib64/samba/libgenrand-samba4.so(log_stack_trace+0x30) [0x7fc53c9ec6b0]
#1 /usr/lib64/samba/libgenrand-samba4.so(smb_panic+0x9) [0x7fc53c9ec909]
#2 /usr/lib64/libsamba-passdb.so.0(+0xe0d7) [0x7fc53d5f00d7]
#3 /usr/lib64/libsamba-passdb.so.0(+0x21555) [0x7fc53d603555]
#4 /usr/lib64/libsamba-passdb.so.0(pdb_create_builtin+0x5d) [0x7fc53d5fe5ad]
#5 /usr/lib64/libsamba-passdb.so.0(create_builtin_administrators+0x2d)
[0x7fc53d5fe76d]
#6 /usr/lib64/libnetapi.so.1(libnet_Join+0x5ae) [0x7fc53d3c9bce]
#7 net(net_ads_join+0x411) [0x5589682cb2c1]
#8 net(net_ads+0x47) [0x5589682d1ec7]
#9 net(main+0xa52) [0x5589682b73e2]
#10 /lib64/libc.so.6(__libc_start_main+0xef) [0x7fc53ad9629d]
#11 net(_start+0x2a) [0x5589682b766a]
Can not dump core: corepath not set up
john
-----Original Message-----
From: samba <samba-bounces at lists.samba.org> On Behalf Of Rowland Penny
via samba
Sent: Thursday, February 9, 2023 2:38 PM
To: samba at lists.samba.org
Cc: Rowland Penny <rpenny at samba.org>
Subject: Re: [Samba] After Suse Enterprise upgrade from 11.4 to 15.4 PCs fails
authentication when trying to mount Samba share
CAUTION: This email message did not come from a Graceland mailbox. Do not click
links or open attachments unless you recognize the sender and know the content
is safe.
On 09/02/2023 20:00, John Adamski (Work Account) wrote:> Thanks for the reply. I have a question or two to clarify what you stated.
>
> First the ranges in the idmap settings was what the SUSE tech that had the
case suggested. I just left them large after they closed the case. I will try
setting them back to normal range.
The problem is, if you change the ranges, you change file ownership, so by that
guy changing them, they changed file ownership if any new files have been
created.
>
> Second the password server line has been include and excluded on different
tries, I think was left in from last things the SUSE tech had me try. I will
comment out and see if that helps.
>
> Now to my clarification question(s):
>
> I don't understand these comments:
>
>> idmap config GRACELAND:unix_nss_info = yes
>
> Only used with the 'ad' idmap backend
>
>> idmap config GRACELAND : backend = tdb
>
> Here is the biggy, the 'tdb' idmap shouldn't be used for the
main
> domain, you should be using 'ad', 'rid', 'autorid'
or 'nss' idmap
> backends
>
> I am not sure which config lines you are talking about and what they should
be instead. Can you clarify?
>
There are various idmap backends:
You can read the documentation for each backend by entering 'man
idmap-BACKEND' where 'BACKEND' can be:
tdb
ad
rid
autorid
nss
NOTE: there are others, but they are the main ones used.
tdb: This an allocating backend and is used for the default domain '*'
ad: This requires that users are given a UidNumber attribute containing a unique
number in the DOMAIN range, Domain Users must also have a gidNumber attribute.
Any group that you require to be visible to Unix must also have a gidNumber
attribute. You can also use the other RFC2307 attributes
rid: This calculates the Unix user and group ID's from the user or group RID
using the low DOMAIN range set in smb.conf
autorid: works similar to 'rid' but is used for multiple domains.
nss: requires local users and groups to match AD user and groups
NOTE: 'DOMAIN' above refers to the worgroup name.
The 'idmap config' lines that I referred to only have relevance if you
use the 'ad' idmap backend
You said:
The ERP requires local Linux user accounts and local group for security so
can't get this from AD.
I don't know if you noticed my reply:
Yes you can
Properly set up, Samba makes AD users into local users.
If you accept that the output from 'getent passwd A_USERNAME' shows
local users, then:
getent passwd rowland
rowland:*:11104:10513:Rowland Penny:/home/rowland:/bin/bash
Means that 'rowland is a local user, right ?
Then what do you make of this:
rowland at devstation:~$ grep 'rowland' /etc/passwd rowland at
devstation:~$
Rowland is not in /etc/passwd
And
rowland at devstation:~$ wbinfo -u | grep rowland rowland
wbinfo reads from AD, so 'rowland' only exists in AD, but is a local
Unix user.
Any further questions etc, please ask.
Rowland
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba