SOLVED FreeNAS + FreeIPA - New users can't access samba. "The security database is corrupted".

phil-k

Cadet
Joined
Mar 19, 2019
Messages
8
Hello all

As a preface, I did not develop this system of FreeNAS with FreeIPA LDAP authentication in our environment. Unfortunately that individual is no longer at our disposal. I'll do my best to answer questions or pull logging or other details that might be helpful.

The setup:
Freenas mini xl enclosure running FreeNAS-11.0-U4 (54848d13b)
FreeIPA, version: 4.5.0

To be clear, this system did work correctly for some time. New users could be created in FreeIPA, have proper security groups applied to them and access to samba network shares would be immediately available.

The Issue:
At some point in time, a problem with the system occurred. It was not an immediately noticeable, and was only discovered when a new hire was brought on and I had to create them an account that required network share access. The entire process of creating the account in FreeIPA, applying security groups was completely normal. Additionally we have two other systems that authenticate through FreeIPA (vpn and password vault). Both of these things are completely unaffected and authentication continues to work fine for all new users.

The issue seems to be limited strictly to authenticating to FreeNAS samba shares. After properly creating a new user, ensuring their appropriate security groups are set and their password is in good standing, I attempt to mount or even directly access the network share and am met with the following error:


"\\network\adress is not accessible. You might not have permission to use this network resource. Contact the administrator of this server to find out if you have access permissions.

The security database is corrupted."


It is also very important to know that this problem only affects new users created after the date when this problem first started. I can add new security groups to users who were created prior to this breaking and they will be able to access those samba shares without issue.

I apologize that I am not more knowledgeable on these two system. I only have a basic understanding of this setup and at this point its been dumped in my lap and I need some advice. I'm really not even sure if this is a FreeNAS issue or a FreeIPA issue. The error leads me to believe its an issue with authentication (FreeIPA) but the fact that the other two systems (vpn and password vault) are still working fine for new users makes me think its a FreeNAS issue.

Any input, troubleshooting advice, etc, would be greatly appreciated.

Thank you very much for any support you can lend.

Phil


Resolved update: This was resolved by ensuring all users have a base GID assigned. You can see the troubleshooting steps that led to this below.
 
Last edited:

phil-k

Cadet
Joined
Mar 19, 2019
Messages
8
50 views but no responses. I'm wondering if someone could give me an idea of why. Is my post lacking certain info or is the FreeNAS + FreeIPA just not widely used and people aren't sure how to assist? I notice there is not a lot of other people using this setup. Maybe its just too niche?
Thanks!
 
D

dlavigne

Guest
Were you able to resolve this or figure out the cause of the corrupt database?
 

phil-k

Cadet
Joined
Mar 19, 2019
Messages
8
Were you able to resolve this or figure out the cause of the corrupt database?
Nope I've gotten no where with it. Though honestly ive not messed with it. I dont know enough about the system to start "trying" suff out becuase if i imapct the partial function we currently have, it could be far more impacting to OPs than it already is. I feel like the resolution would be to start a new DB but im not really sure how to go about that. I'll have to do some extensive reading on these two systems. At this point I'm still not entirely sure which system is causing the issue.
 

phil-k

Cadet
Joined
Mar 19, 2019
Messages
8
I spend some time troubleshooting this today and discovered a few things:

1) On my FreeNAS server I found /var/log/samba4/log.smbd. This log seems to keep track of successful and unsuccessful attempts to access samba shares. I attempted to access a share using an account that does not work and received the following:
Code:
[2019/06/24 13:46:01.370523,  2] ../source3/lib/smbldap.c:794(smbldap_open_connection)
  smbldap_open_connection: connection opened
[2019/06/24 13:46:01.390732,  2] ../source3/passdb/pdb_ldap.c:524(init_sam_from_ldap)
  init_sam_from_ldap: Entry found for user: redactedusername
[2019/06/24 13:46:01.412524,  1] ../source3/auth/server_info.c:526(samu_to_SamInfo3)
  Failed to get groups from sam account.
[2019/06/24 13:46:01.412659,  0] ../source3/auth/check_samsec.c:493(check_sam_security)
  check_sam_security: make_server_info_sam() failed with 'NT_STATUS_INTERNAL_DB_CORRUPTION'
[2019/06/24 13:46:01.412737,  2] ../source3/auth/auth.c:315(auth_check_ntlm_password)
  check_ntlm_password:  Authentication for user [redactedusername] -> [redactedusername] FAILED with error NT_STATUS_INTERNAL_DB_CORRUPTION
[2019/06/24 13:46:01.412803,  2] ../auth/gensec/spnego.c:768(gensec_spnego_server_negTokenTarg)
  SPNEGO login failed: NT_STATUS_INTERNAL_DB_CORRUPTION


Based on this log I came to two conclusions:
a) The windows error message indicating security database corruption is likely a misnomer
b) The issue seems to be related to group membership or actually lack thereof

Now for quite some time I have been making FreeIPA accounts using the following command:
Code:
ipa user-add --random


This creates a user with a UID and GID that are identical. I think this is the cause of the "security database corruption". This method of creating a user in FreeIPA went unnoticed as an issue because generally most new hires will never require samba shares and only require a FreeIPA account for authentication to other applications and tools.

To test this theory I created a new user using the following command:
Code:
ipa user-add --gidnumber=gidofaccountingsecuritygroup --random


This created a new user with the GID of the accounting security group. This permitted access to the accounting samba share. From here I further added additional security groups permitting access to other samba shares and those all worked as well.

I'm fairly certain that I had made accounts in the past without specifying a gid number and still was able to provide samba access by simply adding the appropriate security groups after the fact. I could be wrong about that though, I looked through my users to try and find one with confirmed working samba shares and matching UID/GID but couldn't find one. I didn't really spend much time looking though.

As a final test I called an existing impacted user, through the FreeIPA web GUI I changed the users GID to match the GID of the security group that most closely matched their job role, then I mounted the appropriate share on their computer using their credentials and it worked.

It seems to be working now. I don't think I will dig into it much further. If anyone has any sage advice or their own 2 cents im certainly open to an education. For now I've reached a satisfactory solution (which is probably just the correct way of doing things).
 
Top