samba - Mar 2023 - AD Functional Level vs very old SaMBa member server

Well, thank you for still replying to me. The thing is that this particular
SaMBa server is THE original Linux server of my working place, hosting tons
of home made ancient perl and PHP programs written by former colleagues,
and these programs interact with the dozens of SaMBa shares. This is why we
never had the time to fully analyze its structure and upgrade it somehow
while working on other projects. That PAM SMB module is used by the web
server of the mentioned perl and PHP programs.

Now we'd like to raise the functional level of our Windows domain, and
we're afraid, we will have to completely analyze and replace this ancient
server. The smb.conf is basically like the following:

[global]
netbios name = samba1
workgroup = AD
interfaces = 192.168.0.8/24
bind interfaces only = yes
security = domain
username level = 0
password server = 192.168.0.8
encrypt passwords = yes
name resolve order = wins bcast
browsable = yes
strict allocate = yes
unix extensions = no
dos charset = 852
unix charset = ISO8859-2
display charset = ISO8859-2
case sensitive = no
default case = lower
preserve case = yes
short preserve case = yes

Rowland Penny via samba <samba at lists.samba.org> ezt ?rta (id?pont:
2023.
m?rc. 10., P, 15:46):
>
>
> On 10/03/2023 14:18, Tam?s N?meth via samba wrote:
> > Okay then, this sounds very bad :-( One more thing: There is a system
> using
> > PAM SMB (https://www.samba.org/~airlied/) with lanman1 protocol on
port
> > 139. After upgrading our domain level, will we be able to keep some
> MEMBER
> > servers, to which this PAM SMB remains to be able to authenticate via
> > TCP/139 and some kind of NTLM (let's say NTLMv1) authentication,
or even
> > member servers will only authenticate via kerberos?
> >
>
> I have never used that module (to be honest, I had never heard of it),
> but a quick google shows that it seems to be no longer maintained, the
> last update appears to have been in 2005.
>
> Why do feel that you need it ?
> Perhaps if you explained your network as it is now and also (as I
> already asked you) post your existing smb.conf file(s)
>
> Rowland
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>

On 10/03/2023 15:20, Tam?s N?meth via samba wrote:
> Well, thank you for still replying to me. The thing is that this particular
> SaMBa server is THE original Linux server of my working place, hosting tons
> of home made ancient perl and PHP programs written by former colleagues,
> and these programs interact with the dozens of SaMBa shares. This is why we
> never had the time to fully analyze its structure and upgrade it somehow
> while working on other projects. That PAM SMB module is used by the web
> server of the mentioned perl and PHP programs.
> 
> Now we'd like to raise the functional level of our Windows domain, and
> we're afraid, we will have to completely analyze and replace this
ancient
> server.
I think you already know the answer to that :-|
> The smb.conf is basically like the following
> 
> [global]
> netbios name = samba1
> workgroup = AD
> interfaces = 192.168.0.8/24
> bind interfaces only = yes
> security = domain
> username level = 0
> password server = 192.168.0.8
> encrypt passwords = yes
> name resolve order = wins bcast
> browsable = yes
> strict allocate = yes
> unix extensions = no
> dos charset = 852
> unix charset = ISO8859-2
> display charset = ISO8859-2
> case sensitive = no
> default case = lower
> preserve case = yes
> short preserve case = yes

If (using 4.17.5) you remove the defaults, you get this:

[global]
workgroup = AD
interfaces = 192.168.0.8/24
bind interfaces only = yes
security = domain
strict allocate = yes
unix extensions = no
dos charset = 852
unix charset = ISO8859-2
display charset = ISO8859-2

But that isn't enough for AD and here comes the bit that is probably 
going to make your hair turn white:

Your users are probably in /etc/passwd, you cannot do that on a Unix 
domain member, all the users are in AD and winbind maps them to Unix 
users. Your users probably have ID's that start at '1000' and if you
want to keep these ID's, then you are going to have to use the winbind 
'ad' idmap backend, which means that, at a minimum, you will need to add
lines like these (and add uidNumber & gidNumber attributes to AD):

   idmap config * : backend  = tdb
   idmap config * : range = 1000000-999999999
   idmap config AD : backend  = ad
   idmap config AD : schema_mode = rfc2307
   idmap config AD : unix_nss_info = yes
   idmap config AD : range = 1000-999999

Though if you do not care about the existing ID's you could use the 
'rid' idmap backend:

   idmap config * : backend  = tdb
   idmap config * : range = 3000-7999
   idmap config AD : backend  = rid
   idmap config AD : range = 10000-999999

That will calculate the users Unix ID from the users AD RID plus 10000

You will also have to remove the users from /etc/passwd (same goes for 
groups).

You will also have to add a line to your smb.conf:
realm = YOUR.DNS.DOMAIN.IN.UPPERCASE

I think that is enough for you to think about at the moment, except to 
ask, what do all those scripts do ? You might not need some (or all) of 
them with AD.

Rowland