Bug 6454 - Explain why computer accounts need uidNumbers
Summary: Explain why computer accounts need uidNumbers
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.4
Classification: Unclassified
Component: Docs (show other bugs)
Version: unspecified
Hardware: All All
: P3 enhancement
Target Milestone: ---
Assignee: John H Terpstra (mail address dead(
QA Contact: Samba Documentation QA Contact~
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-09 06:36 UTC by Andras Korn
Modified: 2009-08-17 17:02 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andras Korn 2009-06-09 06:36:27 UTC
Hi,

in some circumstances, Samba appears to insist on machine accounts having the posixAccount objectClass (and thus, the uidNumber attribute). However, as I understand it, no code is ever run as the machine account, and neither does it own any files; thus, it doesn't actually need a uidNumber.

In fact, if I create machine accounts in LDAP "manually", without the uidNumber attribute, things still appear to work.

Is there some reason why machine accounts like the one below are insufficient? If so, what is it (and what should I expect to break if I use them anyway)? I have tried to find something about this in the documentation, but failed.

dn: uid=somecomputer$,ou=Computers,dc=some,dc=domain
uid: somecomputer$
objectClass: account
objectClass: sambaSamAccount
sambaAcctFlags: [W          ]
displayName: somecomputer$
sambaSID: S-1-5-21-655183313-499555889-1571944852-9025
sambaNTPassword: 515E26C88C1A26B578F5764189B11424
sambaPwdLastSet: 1242060593
Comment 1 John H Terpstra (mail address dead( 2009-06-09 09:25:08 UTC
Your observations are correct.  I know of no specific requirement for a UID/GID pair for a (machine) trust account.

The history of Samba pre-dates the ability to use an LDAP-based directory backend. The earliest implementations of Samba utilized plain-text password support.  This made it possible to authenticate against the UNIX /etc/passwd database.

When it became necessary to store the Microsoft Windows NT and LanManager encrytped passwords they were stored in the smbpasswd file.  Rather than re-invent the world, the smbpasswd file became an add-on that fills the gap between account information that is needed by the MS Windows client and account information that is available within the UNIX environment.  In later releases the tdbsam backend and LDAPsam backend were added.  Rather than re-invent the whole account credentials handling methodology, the security account management (SAM) functionality attempts to reuse as much common code as is possible.

So part of the answer is that it is just the way this was implemented, so until someone implements a better methodology that's how it is.

Secondly, Windows NT allocates user, group and trust accounts from the same RID (relative identifier) name space.  The key difference between a user or group account, and a trust account is the fact that the trust account ends with a '$' character.  The over-the-wire authentication protocols make no distinction between a user or group account and a trust account - they use the same network function calls.  It therefore makes sense (because it is a simple solution) to use a common authentication process inside Samba.  Since the "add machine account script" is separate from the "add user account script" it is certainly possible not to add the posixAccount objectclass.  As far as I am aware this will not break anything.

Perhaps one of the other team members could comment on the finer details of this question.
Comment 2 John H Terpstra (mail address dead( 2009-08-17 17:02:25 UTC
Since there has been no update or response - I am closing this bug report.