On 10/03/15 11:48, Bob of Donelson Trophy wrote:> > > Okay, so I tried a "Bob thing" and it made no difference. So, no comment > on that. However, I am learning. > > This is 'wbinfo -*' from my DC1: > > root at tdc01:~# wbinfo -u > Administrator > Guest > krbtgt > dns-tdc01 > dns-TDC02 > root at tdc01:~# wbinfo -g > Enterprise Read-Only Domain Controllers > Domain Admins > Domain Users > Domain Guests > Domain Computers > Domain Controllers > Schema Admins > Enterprise Admins > Group Policy Creator Owners > Read-Only Domain Controllers > DnsUpdateProxy > root at tdc01:~# wbinfo -t > checking the trust secret for domain TEST via RPC calls succeeded > > Here is 'wbinfo -*' from my sernet based member server: > > root at mbr01:~# wbinfo -u > administrator > dns-tdc02 > dns-tdc01 > krbtgt > guest > root at mbr01:~# wbinfo -g > allowed rodc password replication group > enterprise read-only domain controllers > denied rodc password replication group > read-only domain controllers > group policy creator owners > ras and ias servers > domain controllers > enterprise admins > domain computers > cert publishers > dnsupdateproxy > domain admins > domain guests > schema admins > domain users > dnsadmins > root at mbr01:~# wbinfo -t > checking the trust secret for domain TEST via RPC calls failed > error code was NT_STATUS_BAD_NETWORK_NAME (0xc00000cc) > failed to call wbcCheckTrustCredentials: WBC_ERR_AUTH_ERROR > Could not check secret > > And here is the 'wbinfo -*' from my Debian backport member server (now > apparently upgraded to Samba 4.1.17) > > root at RPmbr01:~# wbinfo -u > administrator > dns-tdc02 > dns-tdc01 > krbtgt > guest > root at RPmbr01:~# wbinfo -g > allowed rodc password replication group > enterprise read-only domain controllers > denied rodc password replication group > read-only domain controllers > group policy creator owners > ras and ias servers > domain controllers > enterprise admins > domain computers > cert publishers > dnsupdateproxy > domain admins > domain guests > schema admins > domain users > dnsadmins > root at RPmbr01:~# wbinfo -t > checking the trust secret for domain TEST via RPC calls failed > error code was NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND (0xc0000233) > failed to call wbcCheckTrustCredentials: WBC_ERR_AUTH_ERROR > Could not check secret > > Which raises the question, what is going on with the 'wbinfo -t' on both > member servers? >Nothing, try using sudo Rowland
Debian, already 'root'. Isn't the objective to get a 'SAMDOMDomain Admins' group onto the member server? In the usual way to add any group to a linux box? --- ------------------------- Bob Wooden of Donelson Trophy 615.885.2846 (main) www.donelsontrophy.com [1] "Everyone deserves an award!!" On 2015-03-10 06:57, Rowland Penny wrote:> On 10/03/15 11:48, Bob of Donelson Trophy wrote: > >> Okay, so I tried a "Bob thing" and it made no difference. So, no comment on that. However, I am learning. This is 'wbinfo -*' from my DC1: root at tdc01:~# wbinfo -u Administrator Guest krbtgt dns-tdc01 dns-TDC02 root at tdc01:~# wbinfo -g Enterprise Read-Only Domain Controllers Domain Admins Domain Users Domain Guests Domain Computers Domain Controllers Schema Admins Enterprise Admins Group Policy Creator Owners Read-Only Domain Controllers DnsUpdateProxy root at tdc01:~# wbinfo -t checking the trust secret for domain TEST via RPC calls succeeded Here is 'wbinfo -*' from my sernet based member server: root at mbr01:~# wbinfo -u administrator dns-tdc02 dns-tdc01 krbtgt guest root at mbr01:~# wbinfo -g allowed rodc password replication group enterprise read-only domain controllers denied rodc password replication group read-only domain controllers group policy creator owners ras and ias servers domain controllers enterprise admins domain computers cert publishers dnsupdateproxy domain admins domain guests schema admins domain users dnsadmins root at mbr01:~# wbinfo -t checking the trust secret for domain TEST via RPC calls failed error code was NT_STATUS_BAD_NETWORK_NAME (0xc00000cc) failed to call wbcCheckTrustCredentials: WBC_ERR_AUTH_ERROR Could not check secret And here is the 'wbinfo -*' from my Debian backport member server (now apparently upgraded to Samba 4.1.17) root at RPmbr01:~# wbinfo -u administrator dns-tdc02 dns-tdc01 krbtgt guest root at RPmbr01:~# wbinfo -g allowed rodc password replication group enterprise read-only domain controllers denied rodc password replication group read-only domain controllers group policy creator owners ras and ias servers domain controllers enterprise admins domain computers cert publishers dnsupdateproxy domain admins domain guests schema admins domain users dnsadmins root at RPmbr01:~# wbinfo -t checking the trust secret for domain TEST via RPC calls failed error code was NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND (0xc0000233) failed to call wbcCheckTrustCredentials: WBC_ERR_AUTH_ERROR Could not check secret Which raises the question, what is going on with the 'wbinfo -t' on both member servers?> > Nothing, try using sudo > > RowlandLinks: ------ [1] http://www.donelsontrophy.com
On 10/03/15 14:12, Bob of Donelson Trophy wrote:> > > Debian, already 'root'. > > Isn't the objective to get a 'SAMDOMDomain Admins' group onto the member > server? In the usual way to add any group to a linux box? > > --- > > ------------------------- > > Bob Wooden of Donelson Trophy > > 615.885.2846 (main) > www.donelsontrophy.com [1] > > "Everyone deserves an award!!" > > On 2015-03-10 06:57, Rowland Penny wrote: > >> On 10/03/15 11:48, Bob of Donelson Trophy wrote: >> >>> Okay, so I tried a "Bob thing" and it made no difference. So, no comment on that. However, I am learning. This is 'wbinfo -*' from my DC1: root at tdc01:~# wbinfo -u Administrator Guest krbtgt dns-tdc01 dns-TDC02 root at tdc01:~# wbinfo -g Enterprise Read-Only Domain Controllers Domain Admins Domain Users Domain Guests Domain Computers Domain Controllers Schema Admins Enterprise Admins Group Policy Creator Owners Read-Only Domain Controllers DnsUpdateProxy root at tdc01:~# wbinfo -t checking the trust secret for domain TEST via RPC calls succeeded Here is 'wbinfo -*' from my sernet based member server: root at mbr01:~# wbinfo -u administrator dns-tdc02 dns-tdc01 krbtgt guest root at mbr01:~# wbinfo -g allowed rodc password replication group enterprise read-only domain controllers denied rodc password replication group read-only domain controllers group policy creator owners ras and ias servers domain controllers enterprise admins domain computers cert publishers dnsupdateproxy domain adm > ins > domain guests schema admins domain users dnsadmins root at mbr01:~# wbinfo -t checking the trust secret for domain TEST via RPC calls failed error code was NT_STATUS_BAD_NETWORK_NAME (0xc00000cc) failed to call wbcCheckTrustCredentials: WBC_ERR_AUTH_ERROR Could not check secret And here is the 'wbinfo -*' from my Debian backport member server (now apparently upgraded to Samba 4.1.17) root at RPmbr01:~# wbinfo -u administrator dns-tdc02 dns-tdc01 krbtgt guest root at RPmbr01:~# wbinfo -g allowed rodc password replication group enterprise read-only domain controllers denied rodc password replication group read-only domain controllers group policy creator owners ras and ias servers domain controllers enterprise admins domain computers cert publishers dnsupdateproxy domain admins domain guests schema admins domain users dnsadmins root at RPmbr01:~# wbinfo -t checking the trust secret for domain TEST via RPC calls failed error code was NT_STATUS_DOMAIN_CONTROLLER_NOT_FOUND (0xc0000233) failed > to call > wbcCheckTrustCredentials: WBC_ERR_AUTH_ERROR Could not check secret Which raises the question, what is going on with the 'wbinfo -t' on both member servers? >> Nothing, try using sudo >> >> Rowland > > > Links: > ------ > [1] http://www.donelsontrophy.comWell, yes and no :-) Out of the box a debian (or linux) machine looks in /etc/passwd for users and /etc/group for groups. Windows looks into it own version of these two files or if it is joined to the domain, it looks into AD. Unix uses numbers to identify individual users & groups, windows uses the RID on the end of the SID. Each of the above two methods are mutually exclusive, they mean nothing to each other, so some way has to be found to allow each other to talk to each other. This is where samba comes in, by using winbind you can obtain the users (or group) SID and from this get the Unix ID. This relies on the correct setup being used. wbinfo extracts the info from AD via winbind, but as far as I can see, doesn't do this via Unix, so to check you must use 'getent', so before you can go any further 'getent' must return results. Winbind can use a few different backends, but the most used are the 'ad' & 'rid' ones. With the 'ad' backend, your users must have a 'uidNumber' and your groups a 'gidNumber', these numbers must be inside the range that you set in smb.conf. The 'rid' backend is a bit different, the ID number is calculated for you, but again the range that is set in smb.conf must be large enough. From the wbinfo info that you posted earlier, you do not have any normal users, create one on a DC, give this user a uidNumber, give 'Domain Users' & 'Domain Admins' a gidNumber and then try getent again. Rowland