OmniOS -- Netlogon RPC Sealing Support

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

nosense

New Member
Mar 15, 2022
17
0
1
Am I missing something? What is the status of support in OmniOS for Microsoft's requirement of RPC sealing coming July 11, 2023 (two months) already pushed back. It addresses CVE-2022-38023 & CVE-2023-28268. I continue to get NETLOGON 5838 warnings from OmniOS requests even with the latest r151044 updates. I see no additional options related to sealing (signing/encrypting). Background Here >> The April 2023 Updates provide further urgency to Netlogon RPC Sealing - The things that are better left unspoken (dirteam.com)
 

oneplane

Well-Known Member
Jul 23, 2021
844
484
63
Depends on the version of Samba they use I suppose. Any up-to-date version with

Code:
server schannel = yes
server schannel require seal = yes
will do just fine.

Edit: but since the in-kernel SMB stack doesn't use Samba, this doesn't apply here.
 
Last edited:

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
OmniOS 151046 is most current for Illumos,

For older releases check bug and security fix state at

There has been some critical security fixes lately ex
r151038cz (2023-04-27)
Weekly release for w/c 24th of April 2023.
This update requires a reboot

Security Fixes
git has been updated to version 2.31.8, fixing CVE-2023-25652, CVE-2023-25815, CVE-2023-29007.
The openjdk packages have been updated to versions 11.0.19+7 and 1.8.372-07.


To check current state of Illumos SMB development, see


If you have a dedicated question or concern, ask illumos-discuss or illumos-dev

and/or subscribe the OmniOS newsletter


btw:
The Solarish kernelbased SMB server is part of the OS and different to Windows and SAMBA and offers a perfect integration of local Windows SMB groups, ntfs alike ACL and Windows AD sid as extended attributes. (although you can use SAMBA on Solarish) and the main reason for me (beside the unique level of ZFS/OS integration and troublefree ZFS/OS update/downgrades with bootenvironments) to prefer Solaris and its free forks.
 
Last edited:
  • Like
Reactions: oneplane

oneplane

Well-Known Member
Jul 23, 2021
844
484
63
@oneplane, thanks for the input, but OmniOS does not use Samba. SMB is native.
Ah, I mistook this one indeed. I thought it was linux based, but as this was forked from Solaris at some point which does indeed not use Samba as the SMB implementation. Thanks for pointing it out :)
 

nosense

New Member
Mar 15, 2022
17
0
1
@gea, that's a lot of good information, but there is no solution I see. Yes, I have checked all those areas and there is no information pertaining to this issue. Your previous STH post OmniOS update to support secure RPC on Windows AD | ServeTheHome Forums addresses the state of NETLOGON prior to 11/8/2022 that fixed a previous vulnerability by signing OR encrypting the request. That fix now has additional vulnerabilities and if OmniOS does not support the new paradigm of signing AND encrypting (sealing) then a major component of OmniOS will be useless to a significant population of users.

There is a post Feature #15029: AD join observability - illumos gate - illumos that speaks of sealing in illumos, but it is not clear from the context of the post if the term sealing is used correctly since the issue only had to do with encryption causing visibility issues.

Further, r151044 is a current supported version and the initial enforcement date from Microsoft was 4/11/2023. r151046 was only released on 5/1/2023 which was after the stated initial enforcement date. We are now in a limited compatibility mode until the hammer drops on 7/11/2023 and everything breaks. Thus my concern that things are going to break, because I see no work being done to address this issue.

Status: Fully updated Windows Server + fully updated OmniOS = OmniOS NETLOGON warning and impending failure after 7/11/2023!

As stated by @oneplane, sealing IS currently supported in Samba which I run in the same domain under TrueNAS SCALE.
 

oneplane

Well-Known Member
Jul 23, 2021
844
484
63
I did browse the kernel sources for illumos briefly, and it does seem to have all the required code for Sealing itself:

* NTLMSSP Negotiate Flags
* [MS-NLMP] sec. 2.2.2.5


But that does of course not mean that the SSP part is actually re-used in RPC and schannel code. Considering there are windows event log entries I'm assuming it's not wired up all the way or it's not configured to be enabled. Or RPC doesn't use NTLMSSP and the whole implementation on that part doesn't matter at all. And that's where @gea has a point, might be best to ask the mailing list.
 

nosense

New Member
Mar 15, 2022
17
0
1
@oneplane, Thanks, good piece of info. Unfortunately, Illumos does not always equal OmniOS but is usually close. I was trying to find those options to enable sealing, but I don't see them available, or can't find them documented anywhere. At this point in the game it IS a requirement and should be default. The options should only exist to disable sealing at this point for compatibility with legacy systems.
 

oneplane

Well-Known Member
Jul 23, 2021
844
484
63
@oneplane, Thanks, good piece of info. Unfortunately, Illumos does not always equal OmniOS but is usually close. I was trying to find those options to enable sealing, but I don't see them available, or can't find them documented anywhere. At this point in the game it IS a requirement and should be default. The options should only exist to disable sealing at this point for compatibility with legacy systems.
In this case, the same applies to the OmniOS sources: illumos-omnios/ntlmssp.c at acb9f58c55e175a2ac8d5831c6a57dc779f1d9b2 · omniosorg/illumos-omnios (this is the client side, server side does the same). On the other hand, usr/src/uts/common/netsmb/smb_dev.h doesn't have any flags related to sealing, only signing and encryption. So perhaps they added protocol flags but no code to actually do anything with it. It does look like h_flags is set to the server required flags which is then re-used later to communicate back to the server, but if there is no code to actually do the sealing it would never work. From the looks of illumos-omnios/smbd_ntlmssp.c at acb9f58c55e175a2ac8d5831c6a57dc779f1d9b2 · omniosorg/illumos-omnios It seems that all options are considered as the 'signing' checkbox.

So I'd go for a ticket or at least a question on the dev mailing list to see if anyone is already working on it, and if this should be a VOPT or sysctl-style parameter which would also allow you to verify the configuration at will (instead of guessing -- it doesn't appear to actually be reported anywhere in the kernel or logs).
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
You should ask the smb devs at maillist illumos-dev about this. They are usually very helpful.
Topicbox

btw
OmniOS bloody and OpenIndiana is quite ongoing Illumos. The stable OmniOS editions are a freeze of Illumos with only security and bugfixes - not newer features.
 
Last edited:

nosense

New Member
Mar 15, 2022
17
0
1
@gea, I went to Post the question on Topicbox today before coming here, and was surprised to see the question already posted. Thanks! Let's see what they say.
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
I have googled about the sealing item and it seems mainly related to AD authentication so the only problem should be joining the domain as OmniOS can only be an AD member not an AD server.

I have updated my AD 2019 server to newest and enforced sealing. Then I switched OmniOS to workgroup mode and was able to join the domain without problem. Unless there are further infos, I would not see rpc sealing as a problem for OmniOS.


update
there seems to be another problem after nov14, 2023 with StrongCertificateBindingEnforcement
Guidance on Applying June Microsoft Patch Tuesday Update for CVE-2022-26925 | CISA
 
Last edited:

nosense

New Member
Mar 15, 2022
17
0
1
@gea, well all I can say is I am confused.

Are you saying the mere act of having OmniOS leave the domain but AD account still exists and then rejoining the domain with same AD account fixes the issue? If so, then the rejoin procedure must be rewriting RPC/krb5 settings from their previous settings to some newer settings. Just trying to confirm since I get limited downtimes in order to try things.
 

gea

Well-Known Member
Dec 31, 2010
3,141
1,182
113
DE
@gea, well all I can say is I am confused.

Are you saying the mere act of having OmniOS leave the domain but AD account still exists and then rejoining the domain with same AD account fixes the issue? If so, then the rejoin procedure must be rewriting RPC/krb5 settings from their previous settings to some newer settings. Just trying to confirm since I get limited downtimes in order to try things.
My intension was to check whether OmniOS can join the AD domain/ authenticate when sealing on the AD server is enforced. This seems to work but a SMB user login gives a signing warning. When I additionally enforced StrongCertificateBindingEnforcement (required up from nov 14) I got a signing warning again when I tried to join. I am not deep enough involved into SMB to comment this but Illumos needs to offer a fix for the problem see Bug #15670: Want support for RPC sealing in Netlogon client - illumos gate - illumos
 
Last edited:

nosense

New Member
Mar 15, 2022
17
0
1
@gea, Yes, I can confirm that the initial fix scenario does NOT work.

Initially I thought I had success, because everything worked after the procedure (no errors or warnings and user access worked fine). Unfortunately, via the magic of AD, the remote site AD server was glad to let OmniOS connect through it and the warnings showed up there. when RequireSeal was enforced at level 2 on that server, everything broke as your deeper inspection revealed. Currently operating @RequireSeal level 1 ... The clock is ticking down to failure now!
 

cmderr

New Member
Jun 20, 2023
3
1
1
Has anyone tested the patch for OmniOS? I have it installed in 151038 and 141046 but still cannot join my system to a an Active Directory domain. KPASSWD fails with not able to connect any KDCs for requested realm. It definitely authenticates to AD as it finds the pre-populated object and eventually disables it -- which is what it was doing before the patch.