Mounting an image via IPMI on a Supermicro motherboard

January 25, 2023 Tech Hardware supermicro bios smb Samba ipmi

I was having some lockup issues with my NAS, and wanted to run Memtest86+.

Thankfully, I have Supermicro motherboard that has IPMI (Intelligent Platform Management Interface), which is an out of band way of remotely administering a server.

Supermicro provides a way of mounting a remote image/ISO via a Samba share, so no need to create a bootable USB stick and then insert it into my NAS.

Unfortunately, Supermicro is stuck in the last century as far as security goes for mounting anything using Samba, and it took a bit of investigative work to get it to work.

tl;dr

To mount an image/ISO on a Supermicro motherboard using IPMI, you have to modify the Samba server:

Enable SMBv1 to allow the SMBv1 protocol to be negotiated.
Enable NTLMv1 to allow NTLMv1 authentication.

Horrible security from Supermicro in my opinion, but the above is necessary to get it to work correctly.

I would highly recommend only enabling the above features long enough to mount the image/ISO, as it is a serious downgrade in security for a Samba server.

Determining Supermicro's Samba version request

I knew my Samba configuration was correct, as I was able to mount it without any problems on both a Linux box, and my iMac.

Taking a look at the /var/log/samba/log. log file, I noticed the server terminated the connection with no protocol supported message:

[2023/01/25 14:04:09.170716,  3] ../../source3/smbd/server_exit.c:220(exit_server_common)
  Server exit (no protocol supported
  )

Looking at the log again, I noticed the Supermicro client sent a Requested Protocol [NT LM 0.12]:

[2023/01/25 14:04:09.169987,  3] ../../source3/smbd/negprot.c:636(reply_negprot)
  Requested protocol [NT LM 0.12]

This was confirmed by a packet capture I took of the Samba traffic.

I could also use tshark to filter on the SMB dialect, which would come in handy if we I multiple client's attempting to connect:

tshark -nr smb.pcap -Y "smb" -V -T fields -e smb.dialect.name
NT LM 0.12

From Microsoft's SMB is Dead, Long Live SMB! post, I got a list of SMB1 protocol versions dialect names:

Dialect: PC NETWORK PROGRAM 1.0
Dialect: LANMAN1.0
Dialect: Windows for Workgroups 3.1a
Dialect: LM1.2X002
Dialect: LANMAN2.1
Dialect: NT LM 0.12

Hello WannaCry vulnerability !!

The WannaCry vulnerability popped up in 2017, which quickly led to the SMB1 protocol being disabled everywhere.

My BIOS is from 2020, so I'm not sure why Supermicro hasn't changed the SMB version...

Configure the Samba server to allow SMB1 connections

I use the phrase SMB1 connections here, but what I'm really doing is allowing the SMBv1 protocol to be used/negotiated.

Using the testparm command on the Samba server, I see that by default, the minimum version of SMB that the Samba server will allow is SMB2:

testparm -v | grep 'server min protocol'
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

	server min protocol = SMB2_02

To allow SMB1 connections, I had to add this line under the Global Settings section of /etc/samba/smb.conf (then restart/reload the Samba server):

server min protocol = NT1

However, I still wasn't allowed to log in.

Enable debug password and authentication on the Samba server

Another packet capture showed the Samba server responding to the login attempt with STATUS_LOGIN_FAILURE.

I was using a very simple username/password combination, so I know I wasn't fat fingering it.

Back on the Samba server, I wanted to enable debug logging for the login process, to see why the Samba server was rejecting the login request.

As I was only interested in the authentication and password parts of the login, I enabled debug logging for only authentication and password.

Under the Debugging/Accounting section in the /etc/samba/smb.conf file, I added:

log level = 3 passdb:5 auth:5

After restarting the Samba server and attempting another connection, the /var/log/samba/log. file showed me why it was failing:

[2023/01/25 14:19:20.795048,  2] ../../libcli/auth/ntlm_check.c:472(ntlm_password_check)
  ntlm_password_check: NTLMv1 passwords NOT PERMITTED for user tom
[2023/01/25 14:19:20.795325,  3] ../../libcli/auth/ntlm_check.c:492(ntlm_password_check)
  ntlm_password_check: Lanman passwords NOT PERMITTED for user tom

Using the testparm command again, I saw that the Samba server would only accept NTLMv2 authentication:

testparm -v | egrep 'ntlm auth'
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

	ntlm auth = ntlmv2-only

Configure the Samba server to allow NTLMv1 authentication

To allow NTLMv1 authentication, under the Authentication section in the /etc/samba/smb.conf file, I added:

ntlm auth = yes

Then restarted the Samba server.

Checking the Samba configuration one last time

Checking the Samba server settings a final time, I can see that it will allow both SMB1 connections, and NTLMv1 authentication:

Using the testparm command to verify that both SMB1 connections, and NTLM1 authentication is configured on the Samba server:

$ testparm -v | egrep 'ntlm auth|server min protocol'
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed
Server role: ROLE_STANDALONE

Press enter to see a dump of your service definitions

	ntlm auth = ntlmv1-permitted
	server min protocol = NT1

Once these changes were made, I was able to mount an image in my Supermicro IPMI server.

Modifying the Docker Samba configuration

I'm a big fan of using Docker, and use it for Samba when needed.

In order to allow both SMB1 connections and NTLMv1 authentication in the dperson / samba Docker container, I had to add these lines under the environment variables:

  - SMB=1
  - GLOBAL=ntlm auth=yes

Do NOT run these configuration options any longer than necessary, as they are a major degradation of security !!!

References

SMB is Dead, Long Live SMB! https://techcommunity.microsoft.com/t5/storage-at-microsoft/smb-is-dead-long-live-smb/ba-p/1185401

CSO - WannaCry explained: A perfect ransomware storm https://www.csoonline.com/article/3227906/wannacry-explained-a-perfect-ransomware-storm.html

Samba Wiki - Setting the Samba Log Level https://wiki.samba.org/index.php/Setting_the_Samba_Log_Level

Github - dperson / samba https://github.com/dperson/samba