I experienced the following problem with an apparent permissions Catch-22 where
there's no "root" user to bootstrap from with Samba-LDAP, and
found several other people experienced it too. I eventually figured out why a
few people are plagued by this problem while most have never seen it, and I
solved it. For everyone else who experiences a similar problem, the explanation
and solution are below.
> Proxy2:/etc/samba# net join -U root
> root's password:
> [2005/07/22 16:02:01, 0] utils/net_ads.c:ads_startup(191)
> ads_connect: Transport endpoint is not connected
> [2005/07/22 16:02:01, 0] rpc_client/cli_netlogon.c:cli_nt_setup_creds(256)
> cli_nt_setup_creds: request challenge failed
> Creation of workstation account failed
> User specified does not have administrator privileges
> Unable to join domain DUCOR.
[trying to fix a winbind problem]> supzli02pdc:/ # net rpc join -U administrator
> Password:
> Create of workstation account failed
> User specified does not have administrator privileges
> Unable to join domain SUPZ.
> [root@ogebenec root]# net join -I 192.168.0.20 -W PGNAPLIKACE -U kaminskiz
-n kaminskiz
> kaminskiz password:
> [2003/10/01 14:12:31, 1] utils/net_ads.c:ads_startup(176)
> ads_connect: Connection refused
> [2003/10/01 14:12:32, 0] rpc_client/cli_netlogon.c:cli_nt_setup_creds(249)
> cli_nt_setup_creds: request challenge failed
> [2003/10/01 14:12:32, 1] utils/net_rpc.c:run_rpc_command(154)
> rpc command function failed! (NT_STATUS_NOT_SUPPORTED)
> Create of workstation account failed
> User specified does not have administrator privileges
> Unable to join domain PGNMAIL1.
> $net rpc user add admin -U root -S TOWER -W PIASKI
> # net rpc join -U admin
> Password:
> Create of workstation account failed
> User specified does not have administrator privileges
> Unable to join domain PIASKI.
> # net join -U samba (??? ? ???? ????? ????????
> ????????????)
> samba password:
> Create of workstation account failed
> User specified does not have administrator privileges
> Unable to join domain DOM.
> # net join -I <SERVER_IP> -U <USER_NAME>
> <USER_NAME>'s password:
> [2005/04/08 10:46:06, 0] utils/net_ads.c:ads_startup(186)
> ads_connect: No such file or directory
> [2005/04/08 10:46:06, 0] rpc_client/cli_netlogon.c:cli_nt_setup_creds(256)
> cli_nt_setup_creds: request challenge failed
> Create of workstation account failed
> User specified does not have administrator privileges
> Unable to join domain <DOMAIN_NAME>.
[trying to add a file server to an existing domain]> server1.example.com
> [2004/09/30 23:36:35, 2] lib/interface.c:add_interface(79)
> added interface ip=192.168.0.150 bcast=192.168.0.255
> nmask=255.255.255.0
> smbadmin's password:
> [2004/09/30 23:36:37, 1] libads/ldap.c:ads_connect(251)
> Failed to get ldap server info
> [2004/09/30 23:36:37, 0] utils/net_ads.c:ads_startup(183)
> ads_connect: No results returned
> [2004/09/30 23:36:37, 1] utils/net_rpc.c:run_rpc_command(141)
> rpc command function failed! (NT_STATUS_ACCESS_DENIED)
> Create of workstation account failed
> User specified does not have administrator privileges
> Unable to join domain RHEL.
> [2004/09/30 23:36:38, 2] utils/net.c:main(792)
> return code = 1
The problem isn't really a Catch-22 despite appearances. Somehow --for
reasons I don't fully understand-- this problem seldom arises either on
older versions of Samba or on Sambas that don't use LDAP or even on new
Samba-LDAP systems that have "migrated" from an older implementation.
All the old advice about using something like `smbpasswd -a root` isn't
relevant, both because smbpasswd is deprecated in Samba 3.x and because most
Samba-LDAP systems are configured to look _only_ to LDAP for their "passdb
backend" and so never see the information you tried to set up through
`smbpasswd`.
Some Samba operations use the _Windows_ privileges. They cannot be performed
even by a Samba superuser if that user doesn't also have the right Windows
privileges. Somewhere _inside_ Samba you need to define what will be the user
you use for joining machines to the domain to include sambaSID
<domainSID>-500 (S-1-5-21-...-500) and sambaPrimaryGroupSID
<domainSID>-512 (S-1-5.21-...512). (These are _Windows_ rules, not
something Samba has added or changed.) Also the user's uidNumber has to be 0
(*nix root equivalent). The rid's 500 (0x1F4: user Domain Administrator) and
512 (0x200: group Domain Administrators) are crucial.
To repeat, the superuser needs to be created _inside_ the Samba-LDAP database.
Nothing you do with smb.conf, Samba supporting commands, or *nix permissions
will be relevent.
It probably makes sense to make the _same_ user you use for LDAP access (which
is probably already set up) also be the Network Administrator.
Also within Samba there need to be three sambaGroupMapping entries for
"Domain Admins" (<domainSID>-512), "Domain Users"
(<domainSID>-513) and "Domain Guests" (<domainSID>-514).
And these three entries have to include corresponsing *nix gidNumber values. (To
minimize confusion, it's probably best to use the same names ["Domain
Admins", "Domain Users", "Domain Guests"] and numbers
[512, 513, 514] on the *nix side.) (If your version of Samba-LDAP can't
handle embedded white space, you'll need to change these names to
DomainAdmins, DomainUsers, and DomainGuests.) If these three entries don't
exist, Windows can get quite unhappy; there might even be warnings about this in
the Samba logs.
(Note _many_ instructions incorrectly give the Windows group numbers 0x200,
0x201, and 0x202 as 200, 201, and 202. Don't be suckered even though this
error has become _very_ widespread. Remember, 0x200=512!=200.)
Folks who use the smbldap-tools to help them migrate have all this set up
already (whether they realize it or not). `smbldap-populate` sets up all the
needed Windows-related infrastructure items in the LDAP database. So all the
folks who use the smbldap-tools never see this problem. Folks who create a brand
new LDAP database via "roll your own" though can easily forget these
entries. It will initially appear that everything works okay, but later the
symptoms of not being able to join workstations to the domain, many `net ...`
commands not working right, and error messages about "administrator
privileges" will arise.
-----
If you're not quite sure which entries need to be made, here's an LDAP
dump of the relevant entries from a working system. On this system user
"Manager" is the superuser used to join workstations to the domain (as
well as the LDAP access bootstrap). The domain SID in this example was
S-1-5-21-4049341300-984804467-2912306435.
====dn: cn=Manager,dc=ipswichschools,dc=org
cn: Manager
objectClass: simpleSecurityObject
objectClass: organizationalRole
objectClass: sambaSamAccount
objectClass: posixAccount
objectClass: shadowAccount
userPassword:: e01ENX0xbEVka1dSNUQzcFhOL0dYaW1CR2V3PT0description: Network and
LDAP administrator
sambaSID: S-1-5-21-4049341300-984804467-2912306435-500
uid: Manager
sambaPrimaryGroupSID: S-1-5-21-4049341300-984804467-2912306435-512
gidNumber: 513
homeDirectory: /sambahome/it/Manager
uidNumber: 0
sambaHomePath: \\CONE-SVR1\Manager
sambaLMPassword: 30E885A764F8325DDA2BD47997BC678C
sambaNTPassword: 7F00FBA67E9258530EC4D71969286CF6
dn: ou=WindowsGroups,dc=ipswichschools,dc=org
ou: WindowsGroups
objectClass: top
objectClass: organizationalUnit
dn: cn=DomainAdmins,ou=WindowsGroups,dc=ipswichschools,dc=org
cn: DomainAdmins
gidNumber: 512
objectClass: posixGroup
objectClass: top
objectClass: sambaGroupMapping
sambaGroupType: 2
sambaSID: S-1-5-21-4049341300-984804467-2912306435-512
displayName: DomainAdmins
description: Windows Domain Administrators
dn: cn=DomainUsers,ou=WindowsGroups,dc=ipswichschools,dc=org
cn: DomainUsers
gidNumber: 513
objectClass: posixGroup
objectClass: top
objectClass: sambaGroupMapping
sambaGroupType: 2
sambaSID: S-1-5-21-4049341300-984804467-2912306435-513
displayName: DomainUsers
description: Windows Domain Users
dn: cn=DomainGuests,ou=WindowsGroups,dc=ipswichschools,dc=org
cn: DomainGuests
gidNumber: 514
description: Windows Domain Guests
objectClass: posixGroup
objectClass: top
objectClass: sambaGroupMapping
sambaGroupType: 2
sambaSID: S-1-5-21-4049341300-984804467-2912306435-514
displayName: DomainGuests
cheers!
--
Chuck Kollars - principal Kollars Informatics
Ipswich, Massachusetts, USA
