Hello,
Hoping someone will have two cents they can lend if you have any ideas on this issue. I believe this is partly a continuation of an issue I had posted about back in May: "Security Database is Corrupted"
We have a FreeNAS box using LDAP that authenticates users via FreeIPA. I have a subset of users who require a particular samba share. Lets say this is the marketing department needing access to the "marketing" samba share. When a user is created in FreeIPA they are assigned a UID and a GID. In this particular case the GID would be that of the marketing security group (their main department) which provides access to the "marketing" samba share.
The problem is that a user with a GID of the marketing security group in FreeIPA can not successfully access the marketing samba share. Additionally if more security groups are added in FreeIPA to provide additional samba access (accounting, managment, etc) they also cannot access any of these shares. On the flip side, a user in accounting with the accounting GID with additional access to marketing and any other samba security groups can access all shares without any issue.
The errors I receive are identical to what I had provided in my original post that I referenced above. To reiterate:
When attempting to mount the share in windows:
In the FreeNAS Samba log at: /var/log/samba4/log.smbd
At that point I was only familiar with the getent command which did not seem to indicate any issues. "getent passwd" and "getent group" seems to show all the correct users and groups that have been configured.
Today however I was turned on to the wbinfo command. If I run "wbinfo -g" its immediately obvious that (keeping with the examples I laid out above) "accounting" is in the list of groups but "marketing" is not. This certainly seems to indicate the source of the issue.
Any idea what would cause that? At this point it certainly seems to be something related to the marketing samba share or security group. I've looked them over multiple times via the GUI's of FreeNAS and FreeIPA, comparing them to the functional "accounting" equivalents but i dont see any real differences. This wbinfo command is the first place where I have seen any disparity.
At this time I have worked around the issue. Initially I thought this was caused (and I reference this in my original post I linked above) becuase I was making FreeIPA accounts for basic users (that dont require samba access) by not providing a GID and letting FreeIPA generate a random GID for that user. Big mistake because now I have a ton of GIDs for individuals where really what should have been done from the get-go was create a basic "user" security group and apply that to all new accounts as a base starting location. Realizing this, I did just that and fixed all the users so their base GID is the basic "user" GID with no particular access permissions. This new "user" group DOES show up in "wbinfo -g" results. So from there it was simple to add the marketing samba security group to their account and get them access. Still no idea why the "marketing" security group does not show up when you enter "wbinfo -g"
Thanks for any insight you can lend. Its greatly appreciated.
Regards,
Phil
Resolved update: Ive not discovered what caused the particular group to not show up. As described above I have resolved this by creating a base group for all users. This is the way it should have been done originally, Im not sure why it was not. If for some reason I ever need to fix the issue with that security group, I will likely just delete it and remake it as all of the other security groups I have made are showing properly.
Hoping someone will have two cents they can lend if you have any ideas on this issue. I believe this is partly a continuation of an issue I had posted about back in May: "Security Database is Corrupted"
We have a FreeNAS box using LDAP that authenticates users via FreeIPA. I have a subset of users who require a particular samba share. Lets say this is the marketing department needing access to the "marketing" samba share. When a user is created in FreeIPA they are assigned a UID and a GID. In this particular case the GID would be that of the marketing security group (their main department) which provides access to the "marketing" samba share.
The problem is that a user with a GID of the marketing security group in FreeIPA can not successfully access the marketing samba share. Additionally if more security groups are added in FreeIPA to provide additional samba access (accounting, managment, etc) they also cannot access any of these shares. On the flip side, a user in accounting with the accounting GID with additional access to marketing and any other samba security groups can access all shares without any issue.
The errors I receive are identical to what I had provided in my original post that I referenced above. To reiterate:
When attempting to mount the share in windows:
Code:
"\\network\address 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."
In the FreeNAS Samba log at: /var/log/samba4/log.smbd
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
At that point I was only familiar with the getent command which did not seem to indicate any issues. "getent passwd" and "getent group" seems to show all the correct users and groups that have been configured.
Today however I was turned on to the wbinfo command. If I run "wbinfo -g" its immediately obvious that (keeping with the examples I laid out above) "accounting" is in the list of groups but "marketing" is not. This certainly seems to indicate the source of the issue.
Any idea what would cause that? At this point it certainly seems to be something related to the marketing samba share or security group. I've looked them over multiple times via the GUI's of FreeNAS and FreeIPA, comparing them to the functional "accounting" equivalents but i dont see any real differences. This wbinfo command is the first place where I have seen any disparity.
At this time I have worked around the issue. Initially I thought this was caused (and I reference this in my original post I linked above) becuase I was making FreeIPA accounts for basic users (that dont require samba access) by not providing a GID and letting FreeIPA generate a random GID for that user. Big mistake because now I have a ton of GIDs for individuals where really what should have been done from the get-go was create a basic "user" security group and apply that to all new accounts as a base starting location. Realizing this, I did just that and fixed all the users so their base GID is the basic "user" GID with no particular access permissions. This new "user" group DOES show up in "wbinfo -g" results. So from there it was simple to add the marketing samba security group to their account and get them access. Still no idea why the "marketing" security group does not show up when you enter "wbinfo -g"
Thanks for any insight you can lend. Its greatly appreciated.
Regards,
Phil
Resolved update: Ive not discovered what caused the particular group to not show up. As described above I have resolved this by creating a base group for all users. This is the way it should have been done originally, Im not sure why it was not. If for some reason I ever need to fix the issue with that security group, I will likely just delete it and remake it as all of the other security groups I have made are showing properly.
Last edited:
