Samba login failures -- < sid S-* > Does Not Belong To Our Domain

Each OES server in an environment that is configured with Samba will have a sambaDomain object unique to the server.  It is typically named HOSTNAME-W.  One of the attributes of this object is sambaSID, which will vary from server to server. 

 

When adding users to samba via iManager (outside of the scope of this document) the user has a SID created which includes the SID of the server plus and RID.  The following example is for user1, who was added as a Samba user on Server1:

 

Note that the SID, up to ...4078 is the same.  The RID portion is appended to the SID.  In this case it is 2204.

 

The changes to Samba now force the server to not ignore the main portion of the SID and to just look at the RID.  The server must now look at the whole SID, which includes the RID, as shown above in the user example.  This can present problems for users that were added as Samba users on a different server (even though the servers belong to the same tree).  The problem is that the user's SID takes on the sambaSID's SID for the server to which it was added.  As an example, take a look at User1 again in comparison to User2.  Both users were added to Server1 and Server2 respectively:

 

While the RIDs vary, the main part of the SID does not.  For this reason login failures may occur for some of the users depending on which server they are trying to login to.  Some of the errors include the following:

            ERROR: tree connect failed: NT_STATUS_ACCESS_DENIED

 

While the expected behavior for Samba is not expected to change (IE revert back to ignoring most of the SID and just look at the RID) it is necessary to make some changes to the OES servers and users in order to get them working again on all servers.

The current solution to resolve this issue due to the changes to samba is to modify the SIDs for most of the servers in the environment, so that they all match.  After modifying the SIDs to match, any user that has a SID that does not contain the SID chosen to synchronize the server sambaSID objects must be removed and re-added as a Samba user (not as an eDirectory user).  When adding the user it must be done on a server where the SID was changed.  Again, this will not destroy the eDirectory user, it will just remove and read the Samba user.  Samba maintains its own database of users.  This is the reason eDirectory users must be LUM enabled before adding them to Samba.

 

It is recommended to list off all of the users and find the SID that is most commonly used.  This will prevent working harder than is needed.  A good way to list off user SIDs for comparison is to use the following command.  It may be necessary to parse out unwanted information (beyond the scope of this document):

 

Notice that the output will vary from user to user, depending on which server this command is run on and their varying SIDs.  The bolded area is the section that must be analyzed.   When complete the SID portion of the user and Primary Group will all be the same (not the RID portion).

 

1. The first step is to remove the users from Samba (not eDirectory) that will be impacted--namely those users that do not have an SID that matches the one that will be utilized in a later step.  This can be accomplished by logging into iManager > File Protocols > Samba > select the server object that has Samba installed on it > select the USERS tab, and remove the users.  This will need to be done on a server by server basis as the USERS tab will only show the users that have a matching SID.  For example, if logging into Server1 and looking at the USERS tab, only user1 would show (and not user2) as it is the only user samba enabled on the server.  The same applies to Server2.  It will only see user2.

 

If the user will not remove, then they may need to be forced out of samba on the command line with the following command:

 

If the user still refuses to be removed from samba, then pdbedit can be used:

 

If the user still fails to remove from the samba database (can be checked by 'pdbedit -Lu <username>') contact Novell Support; however, pdbedit seems to always work.

 

2. Once the affected users have been removed it is time to change the SIDs of the server's sambaDomain objects.  To change the SIDs in the tree, choose the SID you wish to use as the template for the other servers.  Enter iManager > Directory Administration > Modify Object > and browse for the HOSTNAME-W object for the server chosen.  After choosing the object select the OTHER button and browse for the sambaSID Valued attribute.  Open it up and copy the value, which is the SID that will be copied to the other server's sambaDomain objects.  Repeat this for all servers but copy in the value from the first server, replacing the existing value. 

 

3. Once this is complete remove and re-add the users to Samba that have been impacted (those users that don't have a matching SID).  It shouldn't matter which server the users are added to now as all of the sambaDomain objects have the same value in the sambaSID valued attributes.  The easiest way to add users is via iManager.  Following the steps above to remove the users, choose to add the users and browse for the users.  Multiple users can be added at once.

 

Once complete pdbedit -Lw should report that all of the user SIDs as matching.  Each user should also be able to login to every other OES server in the same tree that has Samba installed on it.  In the future, as additional servers are added and samba enabled on them, it will be necessary to change their sambaSIDs to match.