The join works OK, but winbind simply fails to start.
see config and logs below, I am scratching my head.
Why does it "contact" a domain called "MAIN" ? that is the hostname of
that server, not the domain name!
would be nice to get a quick reply, I am at the customer and this should
work asap ....
Thanks!
->
[global]
security = ADS
workgroup = ARBEITSGRUPPE
realm = ARBEITSGRUPPE.MY.TLD
map to guest = Bad User
log file = /var/log/samba/%m.log
log level = 3
idmap config * : backend = tdb
idmap config * : range = 3000-7999
## idmap config for the ARBEITSGRUPPE domain
idmap config ARBEITSGRUPPE:backend = rid
idmap config ARBEITSGRUPPE:schema_mode = rfc2307
idmap config ARBEITSGRUPPE:range = 10000-999999
username map = /etc/samba/user.map
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind refresh tickets = Yes
[2016/12/30 11:38:42.568179, 10, pid=6560, effective(0, 0), real(0, 0),
class=winbind] ../source3/winbindd/winbindd_util.c:232(add_trusted_domain)
idmap config BUILTIN : range = not defined
[2016/12/30 11:38:42.568216, 2, pid=6560, effective(0, 0), real(0, 0),
class=winbind] ../source3/winbindd/winbindd_util.c:257(add_trusted_domain)
Added domain BUILTIN (null) S-1-5-32
[2016/12/30 11:38:42.568235, 10, pid=6560, effective(0, 0), real(0, 0),
class=winbind]
../source3/winbindd/winbindd_cache.c:4663(wcache_tdc_add_domain)
wcache_tdc_add_domain: Adding domain MAIN ((null)), SID
S-1-5-21-2777655458-4002997014-749295002, flags = 0x0, attributes = 0x0,
type = 0x0
[2016/12/30 11:38:42.568257, 10, pid=6560, effective(0, 0), real(0, 0),
class=winbind] ../source3/winbindd/winbindd_cache.c:4466(pack_tdc_domains)
pack_tdc_domains: Packing 2 trusted domains
[2016/12/30 11:38:42.568270, 10, pid=6560, effective(0, 0), real(0, 0),
class=winbind] ../source3/winbindd/winbindd_cache.c:4485(pack_tdc_domains)
pack_tdc_domains: Packing domain BUILTIN (UNKNOWN)
[2016/12/30 11:38:42.568280, 10, pid=6560, effective(0, 0), real(0, 0),
class=winbind] ../source3/winbindd/winbindd_cache.c:4485(pack_tdc_domains)
pack_tdc_domains: Packing domain MAIN (UNKNOWN)
[2016/12/30 11:38:42.568307, 10, pid=6560, effective(0, 0), real(0, 0),
class=winbind] ../source3/winbindd/winbindd_util.c:232(add_trusted_domain)
idmap config MAIN : range = not defined
[2016/12/30 11:38:42.568323, 2, pid=6560, effective(0, 0), real(0, 0),
class=winbind] ../source3/winbindd/winbindd_util.c:257(add_trusted_domain)
Added domain MAIN (null) S-1-5-21-2777655458-4002997014-749295002
[2016/12/30 11:38:42.568347, 10, pid=6560, effective(0, 0), real(0, 0),
class=winbind]
../source3/winbindd/winbindd_cm.c:565(set_domain_online_request)
set_domain_online_request: called for domain MAIN
[2016/12/30 11:38:42.568358, 10, pid=6560, effective(0, 0), real(0, 0),
class=winbind]
../source3/winbindd/winbindd_cm.c:575(set_domain_online_request)
set_domain_online_request: Internal domains are always online
[2016/12/30 11:38:42.568577, 0, pid=6560, effective(0, 0), real(0, 0)]
../lib/util/become_daemon.c:124(daemon_ready)
STATUS=daemon 'winbindd' finished starting up and ready to serve
connections
[2016/12/30 11:38:42.568602, 0, pid=6560, effective(0, 0), real(0, 0)]
../source3/lib/util.c:788(smb_panic_s3)
PANIC (pid 6560): Could not find our domain
[2016/12/30 11:38:42.568879, 0, pid=6560, effective(0, 0), real(0, 0)]
../source3/lib/util.c:899(log_stack_trace)
BACKTRACE: 12 stack frames:
#0 /usr/lib64/libsmbconf.so.0(log_stack_trace+0x1a) [0x7fe0214f080a]
#1 /usr/lib64/libsmbconf.so.0(smb_panic_s3+0x20) [0x7fe0214f08f0]
#2 /usr/lib64/libsamba-util.so.0(smb_panic+0x2f) [0x7fe0241990df]
#3 winbindd(+0x36623) [0x555747980623]
#4 winbindd(rescan_trusted_domains+0x1d) [0x55574798064d]
#5 /usr/lib64/libtevent.so.0(tevent_common_loop_timer_delay+0xcd)
[0x7fe01e6afb0d]
#6 /usr/lib64/libtevent.so.0(+0x9b0a) [0x7fe01e6b0b0a]
#7 /usr/lib64/libtevent.so.0(+0x8227) [0x7fe01e6af227]
#8 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x8d) [0x7fe01e6ab46d]
#9 winbindd(main+0xb7c) [0x55574796f4cc]
#10 /lib64/libc.so.6(__libc_start_main+0xf0) [0x7fe01e0e1620]
#11 winbindd(_start+0x29) [0x55574796fb59]
[2016/12/30 11:38:42.568933, 0, pid=6560, effective(0, 0), real(0, 0)]
../source3/lib/dumpcore.c:318(dump_core)
dumping core in /var/log/samba/cores/winbindd
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Was Samba running before the join ?
Remove this line from your smb.conf:
idmap config ARBEITSGRUPPE:schema_mode = rfc2307
It is not required as you are using the winbind 'rid' backend.
Try stopping all Samba processes, then leave the domain and join again.
Now start smbd, nmbd and winbind.
If this doesn't fix it, can you tell us what OS you are using, What is
the AD DC and post your /etc/hosts, /etc/krb5.conf and /etc/resolv.conf
Rowland
> Was Samba running before the join ?
I can't tell that anymore as I did hundreds of things inbetween.
> Remove this line from your smb.conf:
>
> idmap config ARBEITSGRUPPE:schema_mode = rfc2307
>
> It is not required as you are using the winbind 'rid' backend.
"rid" was just a try as "ad" didn't work and I had no more ideas ...
I 'd maybe prefer "ad" ?
> Try stopping all Samba processes, then leave the domain and join again.
> Now start smbd, nmbd and winbind.
Did so.
leave and join: at first try, nice.
winbindd crashes immediately again.
> If this doesn't fix it, can you tell us what OS you are using, What is
> the AD DC and post your /etc/hosts, /etc/krb5.conf and /etc/resolv.conf
The DC "backup" is latest debian. Converted from NT4 today (you remember
the lengthy thread!) ...
The member server "main" is gentoo linux.
Both run samba-4.2.14.
We can access shares on "main" ! even without winbindd running ...
-
# MEMBER SERVER (-> file services)
# cat /etc/hosts
# IPv4 and IPv6 localhost aliases
127.0.0.1 localhost
::1 localhost
10.0.0.221 main.secret.tld main
10.0.0.224 backup.secret.tld backup
# cat /etc/krb5.conf
[libdefaults]
default_realm = ARBEITSGRUPPE.SECRET.TLD
dns_lookup_realm = false
dns_lookup_kdc = true
# cat /etc/samba/smb.conf
[global]
security = ADS
workgroup = ARBEITSGRUPPE
realm = ARBEITSGRUPPE.SECRET.TLD
map to guest = Bad User
log file = /var/log/samba/%m.log
log level = 3
idmap config * : backend = tdb
idmap config * : range = 3000-7999
## idmap config for the ARBEITSGRUPPE domain
idmap config ARBEITSGRUPPE:backend = rid
idmap config ARBEITSGRUPPE:range = 10000-999999
username map = /etc/samba/user.map
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind refresh tickets = Yes
- and we had an issue joining a win7 client, I provide details on this
later ...
Thank you!
OK, if your domain members short host is 'main', this makes its domain
name 'secret.tld', yet the realm is 'ARBEITSGRUPPE.SECRET.TLD'
ignoring case, 'secret.tld' != 'ARBEITSGRUPPE.SECRET.TLD' and it should.
Rowland
Correct you hosts file to
/etc/hosts
127.0.0.1 localhost
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
# This server name and ip.
10.0.0.221 main.arbeitsgruppe.secret.tld main
10.0.0.224 backup.arbeitsgruppe.secret.tld backup
Second. Post you resolv.conf that was asked already.
That should contain something like:
search arbeitsgruppe.secret.tld
Server IP_of_DC
Remove
map to guest = Bad User
from you smb.conf the default is ok.
Try that and see what happens.
Greetz,
Louis
> -----Oorspronkelijk bericht-----
> Van: samba [mailto:samba-...@lists.samba.org] Namens Stefan G.
> Weichinger via samba
> Verzonden: vrijdag 30 december 2016 12:38
> Aan: sa...@lists.samba.org
> Onderwerp: Re: [Samba] ADS domain member: winbind fails
I am confused what to change now!?
did all that
restarted the 3 services smbd nmbd winbind
winbindd fails immediately:
Dez 30 13:43:48 main systemd[1]: winbindd.service: Main process exited,
code=killed, status=6/ABRT
Dez 30 13:43:48 main systemd[1]: winbindd.service: Unit entered failed
state.
Dez 30 13:43:48 main systemd[1]: winbindd.service: Failed with result
'signal'.
---
but maybe I have to row back anyway:
editing GPOs via RSAT always kicks us off after a few minutes.
Seems that my DC isn't working correctly yet.
[global]
workgroup = ARBEITSGRUPPE
realm = arbeitsgruppe.secret.tld
server role = active directory domain controller
passdb backend = samba_dsdb
dns forwarder = 10.0.0.254
rpc_server:tcpip = no
rpc_daemon:spoolssd = embedded
rpc_server:spoolss = embedded
rpc_server:winreg = embedded
rpc_server:ntsvcs = embedded
rpc_server:eventlog = embedded
rpc_server:srvsvc = embedded
rpc_server:svcctl = embedded
rpc_server:default = external
winbindd:use external pipes = true
idmap_ldb:use rfc2307 = yes
idmap config * : backend = tdb
map archive = No
map readonly = no
store dos attributes = Yes
vfs objects = dfs_samba4 acl_xattr
we can login with old and new users, we see shares ...
root@backup:~# cat /etc/resolv.conf
search arbeitsgruppe.ikw-amstetten.at
nameserver 10.0.0.224
# host -t SRV _ldap._tcp.backup.arbeitsgruppe.ikw-amstetten.at
Host _ldap._tcp.backup.arbeitsgruppe.ikw-amstetten.at not found: 3(NXDOMAIN)
--> this query has worked before
thanks for any help
What is the dns domain of your DC ?
Whatever it is, this will have been used for your kerberos realm.
You will need to use the same dns domain and kerberos realm on your
domain member.
EXAMPLE:
The dns domain of your DC is 'arbeitsgruppe.secret.tld' and the realm
on the DC is 'ARBEITSGRUPPE.SECRET.TLD'
Your dns domain on the domain member will have to be
'arbeitsgruppe.secret.tld' and the realm 'ARBEITSGRUPPE.SECRET.TLD'
Rowland
Is this the smb.conf you got when you ran the classicupgrade ?
I don't think it is, can I suggest you remove any and all lines you
have added and restart samba
Rowland
that was the output of testparm
smb.conf on DC:
[global]
workgroup = ARBEITSGRUPPE
realm = arbeitsgruppe.secret.tld
netbios name = BACKUP
server role = active directory domain controller
idmap_ldb:use rfc2307 = yes
dns forwarder = 10.0.0.254
[netlogon]
path = /var/lib/samba/sysvol/arbeitsgruppe.secret.tld/scripts
read only = No
[sysvol]
path = /var/lib/samba/sysvol
read only = No
--
root@backup:/etc/samba# cat /etc/resolv.conf
search arbeitsgruppe.secret.tld
nameserver 10.0.0.224
root@backup:/etc/samba# cat /etc/krb5.conf
[libdefaults]
default_realm = ARBEITSGRUPPE.SECRET.TLD
dns_lookup_realm = false
dns_lookup_kdc = true
--
editing the resolv.conf(s) helped in stabilizing RSAT editing
winbindd on member still fails, I left and rejoined ...
--
although I see users and GPOs on the member, etc (via net ads)
# net ads info
LDAP server: 10.0.0.224
LDAP server name: backup.arbeitsgruppe.secret.tld
Realm: ARBEITSGRUPPE.SECRET.TLD
Bind Path: dc=ARBEITSGRUPPE,dc=SECRET,dc=TLD
LDAP port: 389
Server time: Fr, 30 Dez 2016 14:24:25 CET
KDC server: 10.0.0.224
Server time offset: 0
> Am 2016-12-30 um 14:07 schrieb Rowland Penny via samba:
> > Is this the smb.conf you got when you ran the classicupgrade ?
> > I don't think it is, can I suggest you remove any and all lines you
> > have added and restart samba
>
> that was the output of testparm
Ah, can I introduce you to 'samba-tool testparm'
What this shows is that your dns domain is 'arbeitsgruppe.secret.tld'
and your domain member should also be using this dns domain. Your
earlier posts seem to suggest you are using 'secret.tld' on the domain
member, this must be changed.
Rowland
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
so you suggest to edit the hostname (did so via hostnamectl set-hostname) ?
did that, left domain and rejoined (on member server, sure), winbindd
fails again
[2016/12/30 15:44:55.762270, 10, pid=9066, effective(0, 0), real(0, 0),
class=winbind] ../source3/winbindd/winbindd_util.c:232(add_trusted_domain)
idmap config BUILTIN : range = not defined
[2016/12/30 15:44:55.762307, 2, pid=9066, effective(0, 0), real(0, 0),
class=winbind] ../source3/winbindd/winbindd_util.c:257(add_trusted_domain)
Added domain BUILTIN (null) S-1-5-32
[2016/12/30 15:44:55.762326, 10, pid=9066, effective(0, 0), real(0, 0),
class=winbind]
../source3/winbindd/winbindd_cache.c:4663(wcache_tdc_add_domain)
wcache_tdc_add_domain: Adding domain MAIN ((null)), SID
S-1-5-21-2777655458-4002997014-749295002, flags = 0x0, attributes = 0x0,
type = 0x0
[2016/12/30 15:44:55.762348, 10, pid=9066, effective(0, 0), real(0, 0),
class=winbind] ../source3/winbindd/winbindd_cache.c:4466(pack_tdc_domains)
pack_tdc_domains: Packing 2 trusted domains
[2016/12/30 15:44:55.762360, 10, pid=9066, effective(0, 0), real(0, 0),
class=winbind] ../source3/winbindd/winbindd_cache.c:4485(pack_tdc_domains)
pack_tdc_domains: Packing domain BUILTIN (UNKNOWN)
[2016/12/30 15:44:55.762370, 10, pid=9066, effective(0, 0), real(0, 0),
class=winbind] ../source3/winbindd/winbindd_cache.c:4485(pack_tdc_domains)
pack_tdc_domains: Packing domain MAIN (UNKNOWN)
[2016/12/30 15:44:55.762391, 10, pid=9066, effective(0, 0), real(0, 0),
class=winbind] ../source3/winbindd/winbindd_util.c:232(add_trusted_domain)
idmap config MAIN : range = not defined
[2016/12/30 15:44:55.762406, 2, pid=9066, effective(0, 0), real(0, 0),
class=winbind] ../source3/winbindd/winbindd_util.c:257(add_trusted_domain)
Added domain MAIN (null) S-1-5-21-2777655458-4002997014-749295002
[2016/12/30 15:44:55.762426, 10, pid=9066, effective(0, 0), real(0, 0),
class=winbind]
../source3/winbindd/winbindd_cm.c:565(set_domain_online_request)
set_domain_online_request: called for domain MAIN
[2016/12/30 15:44:55.762436, 10, pid=9066, effective(0, 0), real(0, 0),
class=winbind]
../source3/winbindd/winbindd_cm.c:575(set_domain_online_request)
set_domain_online_request: Internal domains are always online
[2016/12/30 15:44:55.762649, 0, pid=9066, effective(0, 0), real(0, 0)]
../lib/util/become_daemon.c:124(daemon_ready)
STATUS=daemon 'winbindd' finished starting up and ready to serve
connections
[2016/12/30 15:44:55.762671, 0, pid=9066, effective(0, 0), real(0, 0)]
../source3/lib/util.c:788(smb_panic_s3)
PANIC (pid 9066): Could not find our domain
[2016/12/30 15:44:55.762942, 0, pid=9066, effective(0, 0), real(0, 0)]
../source3/lib/util.c:899(log_stack_trace)
BACKTRACE: 12 stack frames:
#0 /usr/lib64/libsmbconf.so.0(log_stack_trace+0x1a) [0x7f907b4247aa]
#1 /usr/lib64/libsmbconf.so.0(smb_panic_s3+0x20) [0x7f907b424890]
#2 /usr/lib64/libsamba-util.so.0(smb_panic+0x2f) [0x7f907e0ce0df]
#3 winbindd(+0x36623) [0x564b39618623]
#4 winbindd(rescan_trusted_domains+0x1d) [0x564b3961864d]
#5 /usr/lib64/libtevent.so.0(tevent_common_loop_timer_delay+0xcd)
[0x7f90785e2b0d]
#6 /usr/lib64/libtevent.so.0(+0x9b0a) [0x7f90785e3b0a]
#7 /usr/lib64/libtevent.so.0(+0x8227) [0x7f90785e2227]
#8 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x8d) [0x7f90785de46d]
#9 winbindd(main+0xb7c) [0x564b396074cc]
#10 /lib64/libc.so.6(__libc_start_main+0xf0) [0x7f9078014620]
#11 winbindd(_start+0x29) [0x564b39607b59]
[2016/12/30 15:44:55.762995, 0, pid=9066, effective(0, 0), real(0, 0)]
../source3/lib/dumpcore.c:318(dump_core)
dumping core in /var/log/samba/cores/winbindd
-
interestingly old users work: my understanding is that as the upcoming
*member* server is the old NT4-PDC -> it has the old domain users in
/etc/passwd and so logins work without winbind, correct?
-
as I see in the logs above, winbind contacts *other* domains, and not
"ARBEITSGRUPPE" ... why that?
pls note that my "idmap *" lines for the member server are just cut and
paste mainly, maybe the ranges are bogus or something else.
I will now reply to Louis and provide configs.
No, not the hostname, the domain name, what does 'hostname -s',
'hostname -d' and 'hostname -f' show ?
Rowland
No:
debian = DC
gentoo = former NT4-PDC, upcoming member server / fileserver
>
> Did you add in /etc/ldap/ldap.conf
>
> TLS_REQCERT allow
on the member?
Did that right now.
> apt-get install ca-certificates
> echo “TLS_REQCERT allow” > /etc/ldap/ldap.conf
>
>
>
> Locate you SAMBA CA root.
>
> ln -s path_to_samba_TLS-CA-ROOT /usr/local/share/ca-certificates/samba-ca.crt
will dig that up on gentoo now ...
> Do that on the debian server, reboot it and after reboot type wbinfo –u
> And post /etc/hosts /etc/resolv.conf /etc/samba/smb.conf of that server.
you speak of the member server?
main samba # cat /etc/hosts
# IPv4 and IPv6 localhost aliases
127.0.0.1 localhost
::1 localhost
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.0.0.221 main.secret.tld main
10.0.0.222 samba.secret.tld samba
10.0.0.224 backup.secret.tld backup
10.0.0.225 vmware.secret.tld vmware
main samba # cat /etc/resolv.conf
# Generated by net-scripts for interface eth0
search arbeitsgruppe.secret.tld
nameserver 10.0.0.224
main samba # cat /etc/samba/smb.conf
[global]
security = ADS
workgroup = ARBEITSGRUPPE
realm = arbeitsgruppe.secret.tld
log file = /var/log/samba/%m.log
log level = 3
idmap config * : backend = tdb
idmap config * : range = 3000-7999
## idmap config for the ARBEITSGRUPPE domain
idmap config ARBEITSGRUPPE:backend = rid
idmap config ARBEITSGRUPPE:range = 10000-999999
username map = /etc/samba/user.map
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind refresh tickets = Yes
[Daten]
comment = Daten
path = /mnt/daten
#valid users = @users
force group = users
read only = No
create mask = 0660
directory mask = 0770
we can't join win7 clients.
[2016/12/30 16:13:53.836745, 0]
../source4/dsdb/common/util_samr.c:192(dsdb_add_user)
Failed to create user record
CN=ZBOOK,CN=Computers,DC=arbeitsgruppe,DC=secret,DC=tld: acl: unable to
find or validate structural objectClass on
CN=ZBOOK,CN=Computers,DC=arbeitsgruppe,DC=secret,DC=tld
--
while the OU / container seems to exist:
~# ldbsearch -H ldap://backup -U Administrator | grep "CN=Computers"
dn: CN=W7TEST,CN=Computers,DC=arbeitsgruppe,DC=secret,DC=tld
distinguishedName: CN=W7TEST,CN=Computers,DC=arbeitsgruppe,DC=secret,DC
dn: CN=main,CN=Computers,DC=arbeitsgruppe,DC=secret,DC=tld
-
# samba-tool dbcheck
Checking 356 objects
Checked 356 objects (0 errors)
SOLVED, sorry.
we have to use Administrator now, not "root"
> No, not the hostname, the domain name, what does 'hostname -s',
> 'hostname -d' and 'hostname -f' show ?
main ~ # hostname -s
main
main ~ # hostname -d
arbeitsgruppe.secret.tld
main ~ # hostname -f
main.arbeitsgruppe.secret.tld
> Hai Rowland,
>
> Oeps.. wrong one, but now he knows. :-/
> See below.
>
OK, check and alter where required the following files:
/etc/hosts
# IPv4 and IPv6 localhost aliases
127.0.0.1 localhost
::1 localhost
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
10.0.0.221 main.arbeitsgruppe.secret.tld main
That is all it should contain, provided 10.0.0.221 is the ipaddress of
main.arbeitsgruppe.secret.tld
/etc/hostname
This should just contain the short hostname 'main'
/etc/resolv.conf
search arbeitsgruppe.secret.tld
nameserver 10.0.0.224
This is provided 10.0.0.224 is the ipaddress of an AD DC running a dns
server.
/etc/krb5.conf
[libdefaults]
default_realm = ARBEITSGRUPPE.SECRET.TLD
dns_lookup_realm = false
dns_lookup_kdc = true
If everything is setup as above you should be able to join the gentoo
domain member to the domain and then start the nmbd, smbd and winbind
deamons.
Rowland
maybe something else needed on gentoo
I currently research pam_winbind.
But that *depends* on a running winbindd, correct?
I still wonder about these lines in the log:
[2016/12/30 16:57:45.651253, 2]
../source3/winbindd/winbindd_util.c:257(add_trusted_domain)
Added domain BUILTIN (null) S-1-5-32
[2016/12/30 16:57:45.651327, 2]
../source3/winbindd/winbindd_util.c:257(add_trusted_domain)
Added domain MAIN (null) S-1-5-21-2777655458-4002997014-749295002
[2016/12/30 16:57:45.651641, 0]
../lib/util/become_daemon.c:124(daemon_ready)
STATUS=daemon 'winbindd' finished starting up and ready to serve
connections
[2016/12/30 16:57:45.651671, 0] ../source3/lib/util.c:788(smb_panic_s3)
PANIC (pid 5357): Could not find our domain
Which domain does it not find, how to set that?
everything checked and set up as mentioned
Waiting for samba to *recompile* here, I wonder if the updated
tevent-package makes a difference.
I will stop the 3 daemons, leave and rejoins, then start the 3.
Particular order?
> If everything is setup as above you should be able to join the gentoo
> domain member to the domain and then start the nmbd, smbd and winbind
> deamons.
sad to say:
leave and join works without a problem, but then ->
winbindd.service - Samba Winbind daemon
Loaded: loaded (/usr/lib64/systemd/system/winbindd.service;
disabled; vendor preset: enabled)
Active: failed (Result: signal) since Fr 2016-12-30 17:22:46 CET; 5s ago
Process: 2540 ExecStart=/usr/sbin/winbindd -D (code=exited,
status=0/SUCCESS)
Main PID: 2543 (code=killed, signal=ABRT)
Dez 30 17:22:46 main.arbeitsgruppe.secret.tld systemd[1]: Starting Samba
Winbind daemon...
Dez 30 17:22:46 main.arbeitsgruppe.secret.tld systemd[1]: Started Samba
Winbind daemon.
Dez 30 17:22:46 main.arbeitsgruppe.secret.tld systemd[1]:
winbindd.service: Main process exited, code=killed, status=6/ABRT
Dez 30 17:22:46 main.arbeitsgruppe.secret.tld systemd[1]:
winbindd.service: Unit entered failed state.
Dez 30 17:22:46 main.arbeitsgruppe.secret.tld systemd[1]:
winbindd.service: Failed with result 'signal'.
->
main samba # wbinfo -u
could not obtain winbind interface details: WBC_ERR_WINBIND_NOT_AVAILABLE
could not obtain winbind domain name!
Error looking up domain users
---
OK, try this, open a terminal, type 'winbindd -i'
This should directly run winbind in the terminal, hopefully if it fails
it will print an error message, if not try again but add '-d3'
Rowland
> OK, try this, open a terminal, type 'winbindd -i'
> This should directly run winbind in the terminal, hopefully if it fails
> it will print an error message, if not try again but add '-d3'
main ~ # winbindd -i -d3
Maximum core file size limits now 16777216(soft) -1(hard)
winbindd version 4.2.14 started.
Copyright Andrew Tridgell and the Samba Team 1992-2014
lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[global]"
Maximum core file size limits now 16777216(soft) -1(hard)
Registered MSG_REQ_POOL_USAGE
Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED
lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[global]"
added interface br0 ip=10.0.0.221 bcast=10.0.0.255 netmask=255.255.255.0
added interface br0 ip=10.0.0.221 bcast=10.0.0.255 netmask=255.255.255.0
initialize_winbindd_cache: clearing cache and re-creating with version
number 2
Added domain BUILTIN (null) S-1-5-32
Added domain MAIN (null) S-1-5-21-2777655458-4002997014-749295002
PANIC (pid 3155): Could not find our domain
BACKTRACE: 12 stack frames:
#0 /usr/lib64/libsmbconf.so.0(log_stack_trace+0x1a) [0x7fc11e4ac7aa]
#1 /usr/lib64/libsmbconf.so.0(smb_panic_s3+0x20) [0x7fc11e4ac890]
#2 /usr/lib64/libsamba-util.so.0(smb_panic+0x2f) [0x7fc1211560df]
#3 winbindd(+0x36623) [0x55d385353623]
#4 winbindd(rescan_trusted_domains+0x1d) [0x55d38535364d]
#5 /usr/lib64/libtevent.so.0(tevent_common_loop_timer_delay+0xcd)
[0x7fc11b66ab0d]
#6 /usr/lib64/libtevent.so.0(+0x9b0a) [0x7fc11b66bb0a]
#7 /usr/lib64/libtevent.so.0(+0x8227) [0x7fc11b66a227]
#8 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x8d) [0x7fc11b66646d]
#9 winbindd(main+0xb7c) [0x55d3853424cc]
#10 /lib64/libc.so.6(__libc_start_main+0xf0) [0x7fc11b09c620]
#11 winbindd(_start+0x29) [0x55d385342b59]
dumping core in /var/log/samba/cores/winbindd
Abgebrochen
question:
could it be that some old cruft in /var/lib/samba bites here?
how to get rid of that? rm-ing it completely messed up joining (tried
that before), so it seems I have to clean up some files only.
remember: server "main" was nt4-pdc ~~ and we only replaced smb.conf and
joined etc etc // maybe too bold? ;-)
main samba # tree /var/lib/samba/
/var/lib/samba/
├── account_policy.tdb
├── browse.dat
├── group_mapping.tdb
├── netlogon
│ └── logon.bat
├── perfmon
├── printing
├── private
│ ├── netlogon_creds_cli.tdb
│ ├── passdb.tdb
│ ├── schannel_store.tdb
│ ├── secrets.tdb
│ ├── smbd.tmp
│ │ └── msg
│ │ ├── msg.3250
│ │ ├── msg.3262
│ │ └── names.tdb
│ └── smbpasswd
├── registry.tdb
├── share_info.tdb
├── var
│ └── lib
│ └── samba
├── winbindd_cache.tdb
└── winbindd_privileged
└── pipe
ah, btw. rm-ing winbindd_cache.tdb did not help winbindd either.
bye for now
>
> got to leave here, can look up in 1-2hrs again from home office
>
> question:
> could it be that some old cruft in /var/lib/samba bites here?
> how to get rid of that? rm-ing it completely messed up joining (tried
> that before), so it seems I have to clean up some files only.
>
> remember: server "main" was nt4-pdc ~~ and we only replaced smb.conf
> and joined etc etc // maybe too bold? ;-)
Oh definitely, you will probably have to empty /var/lib/samba and then
let Samba fill it up again.
Rowland
From that I see you are using Samba 4.2.14 , is there a possibility of
two smb.conf files or other duplicate Samba binaries ?
Have installed all the required dependencies, see here:
https://wiki.samba.org/index.php/Samba_Dependencies_Required_to_Build_Samba
What is happening is that when winbind is started, it adds the 'BUILTIN'
domain, then the local 'MAIN' domain, it then panics when it tries to
add the AD domain.
All I can suggest is double checking you have all the dependencies
installed to build Samba on gentoo.
Rowland
-d10 please :-)
Volker
> On Fri, Dec 30, 2016 at 05:55:58PM +0100, Stefan G. Weichinger via
> samba wrote:
> > Am 2016-12-30 um 17:42 schrieb Rowland Penny via samba:
> >
> > >OK, try this, open a terminal, type 'winbindd -i'
> > >This should directly run winbind in the terminal, hopefully if it
> > >fails it will print an error message, if not try again but add
> > >'-d3'
> >
> >
> > main ~ # winbindd -i -d3
>
> -d10 please :-)
>
> Volker
>
I would have worked up to that ;-)
But the OP has since posted that he just changed the smb.conf on his
old PDC and didn't empty /var/lib/samba
Rowland
Am 30. Dezember 2016 18:53:22 MEZ schrieb Volker Lendecke <v...@samba.org>:
>On Fri, Dec 30, 2016 at 05:55:58PM +0100, Stefan G. Weichinger via
>samba wrote:
>> Am 2016-12-30 um 17:42 schrieb Rowland Penny via samba:
>>
>> >OK, try this, open a terminal, type 'winbindd -i'
>> >This should directly run winbind in the terminal, hopefully if it
>fails
>> >it will print an error message, if not try again but add '-d3'
>>
>>
>> main ~ # winbindd -i -d3
>
>-d10 please :-)
>
>Volker
--
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
>> -d10 please :-)
>>
>> Volker
>>
>
> I would have worked up to that ;-)
>
> But the OP has since posted that he just changed the smb.conf on his
> old PDC and didn't empty /var/lib/samba
emptying /var/lib/samba caused issues with joining: no secrets.tdb
->
main ~ # winbindd -i -d10
INFO: Current debug levels:
all: 10
tdb: 10
printdrivers: 10
lanman: 10
smb: 10
rpc_parse: 10
rpc_srv: 10
rpc_cli: 10
passdb: 10
sam: 10
auth: 10
winbind: 10
vfs: 10
idmap: 10
quota: 10
acls: 10
locking: 10
msdfs: 10
dmapi: 10
registry: 10
scavenger: 10
dns: 10
ldb: 10
Maximum core file size limits now 16777216(soft) -1(hard)
winbindd version 4.2.14 started.
Copyright Andrew Tridgell and the Samba Team 1992-2014
lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
INFO: Current debug levels:
all: 10
tdb: 10
printdrivers: 10
lanman: 10
smb: 10
rpc_parse: 10
rpc_srv: 10
rpc_cli: 10
passdb: 10
sam: 10
auth: 10
winbind: 10
vfs: 10
idmap: 10
quota: 10
acls: 10
locking: 10
msdfs: 10
dmapi: 10
registry: 10
scavenger: 10
dns: 10
ldb: 10
Processing section "[global]"
doing parameter security = ADS
doing parameter workgroup = ARBEITSGRUPPE
doing parameter realm = arbeitsgruppe.secret.tld
doing parameter log file = /var/log/samba/%m.log
doing parameter log level = 8
doing parameter idmap config * : backend = tdb
doing parameter idmap config * : range = 3000-7999
doing parameter idmap config ARBEITSGRUPPE:backend = rid
doing parameter idmap config ARBEITSGRUPPE:range = 10000-999999
doing parameter username map = /etc/samba/user.map
doing parameter winbind enum users = Yes
doing parameter winbind enum groups = Yes
doing parameter winbind use default domain = Yes
doing parameter winbind refresh tickets = Yes
pm_process() returned Yes
lp_servicenumber: couldn't find homes
Maximum core file size limits now 16777216(soft) -1(hard)
Registering messaging pointer for type 2 - private_data=(nil)
Registering messaging pointer for type 9 - private_data=(nil)
Registered MSG_REQ_POOL_USAGE
Registering messaging pointer for type 11 - private_data=(nil)
Registering messaging pointer for type 12 - private_data=(nil)
Registered MSG_REQ_DMALLOC_MARK and LOG_CHANGED
Registering messaging pointer for type 1 - private_data=(nil)
Registering messaging pointer for type 5 - private_data=(nil)
lp_load_ex: refreshing parameters
Freeing parametrics:
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
INFO: Current debug levels:
all: 10
tdb: 10
printdrivers: 10
lanman: 10
smb: 10
rpc_parse: 10
rpc_srv: 10
rpc_cli: 10
passdb: 10
sam: 10
auth: 10
winbind: 10
vfs: 10
idmap: 10
quota: 10
acls: 10
locking: 10
msdfs: 10
dmapi: 10
registry: 10
scavenger: 10
dns: 10
ldb: 10
Processing section "[global]"
doing parameter security = ADS
doing parameter workgroup = ARBEITSGRUPPE
doing parameter realm = arbeitsgruppe.secret.tld
doing parameter log file = /var/log/samba/%m.log
doing parameter log level = 8
doing parameter idmap config * : backend = tdb
doing parameter idmap config * : range = 3000-7999
doing parameter idmap config ARBEITSGRUPPE:backend = rid
doing parameter idmap config ARBEITSGRUPPE:range = 10000-999999
doing parameter username map = /etc/samba/user.map
doing parameter winbind enum users = Yes
doing parameter winbind enum groups = Yes
doing parameter winbind use default domain = Yes
doing parameter winbind refresh tickets = Yes
pm_process() returned Yes
lp_servicenumber: couldn't find homes
added interface br0 ip=10.0.0.221 bcast=10.0.0.255 netmask=255.255.255.0
Netbios name list:-
my_netbios_names[0]="MAIN"
added interface br0 ip=10.0.0.221 bcast=10.0.0.255 netmask=255.255.255.0
Process with PID=3459 does not exist.
Deleting /run/samba/winbindd.pid, since 3459 is not a Samba process.
fcntl_lock 9 6 0 1 1
fcntl_lock: Lock call successful
TimeInit: Serverzone is -3600
initialize_winbindd_cache: clearing cache and re-creating with version
number 2
check lock order 2 for /var/lock/samba/serverid.tdb
lock order: 1:<none> 2:/var/lock/samba/serverid.tdb 3:<none>
Locking key AF19000000000000FFFF
Allocated locked data 0x0x55938c9a5e80
Unlocking key AF19000000000000FFFF
release lock order 2 for /var/lock/samba/serverid.tdb
lock order: 1:<none> 2:<none> 3:<none>
Registering messaging pointer for type 33 - private_data=(nil)
Registering messaging pointer for type 13 - private_data=(nil)
Registering messaging pointer for type 1028 - private_data=(nil)
Registering messaging pointer for type 1027 - private_data=(nil)
Registering messaging pointer for type 1029 - private_data=(nil)
Registering messaging pointer for type 1036 - private_data=(nil)
Registering messaging pointer for type 1035 - private_data=(nil)
Registering messaging pointer for type 1280 - private_data=(nil)
Registering messaging pointer for type 1032 - private_data=(nil)
Registering messaging pointer for type 1033 - private_data=(nil)
Registering messaging pointer for type 1034 - private_data=(nil)
Registering messaging pointer for type 1 - private_data=(nil)
Overriding messaging pointer for type 1 - private_data=(nil)
wcache_tdc_add_domain: Adding domain BUILTIN ((null)), SID S-1-5-32,
flags = 0x0, attributes = 0x0, type = 0x0
pack_tdc_domains: Packing 1 trusted domains
pack_tdc_domains: Packing domain BUILTIN (UNKNOWN)
idmap config BUILTIN : range = not defined
Added domain BUILTIN (null) S-1-5-32
wcache_tdc_add_domain: Adding domain MAIN ((null)), SID
S-1-5-21-2777655458-4002997014-749295002, flags = 0x0, attributes = 0x0,
type = 0x0
pack_tdc_domains: Packing 2 trusted domains
pack_tdc_domains: Packing domain BUILTIN (UNKNOWN)
pack_tdc_domains: Packing domain MAIN (UNKNOWN)
idmap config MAIN : range = not defined
Added domain MAIN (null) S-1-5-21-2777655458-4002997014-749295002
set_domain_online_request: called for domain MAIN
set_domain_online_request: Internal domains are always online
PANIC (pid 6575): Could not find our domain
BACKTRACE: 12 stack frames:
#0 /usr/lib64/libsmbconf.so.0(log_stack_trace+0x1a) [0x7ff0b02a97aa]
#1 /usr/lib64/libsmbconf.so.0(smb_panic_s3+0x20) [0x7ff0b02a9890]
#2 /usr/lib64/libsamba-util.so.0(smb_panic+0x2f) [0x7ff0b2f530df]
#3 winbindd(+0x36623) [0x55938b418623]
#4 winbindd(rescan_trusted_domains+0x1d) [0x55938b41864d]
#5 /usr/lib64/libtevent.so.0(tevent_common_loop_timer_delay+0xcd)
[0x7ff0ad467b0d]
#6 /usr/lib64/libtevent.so.0(+0x9b0a) [0x7ff0ad468b0a]
#7 /usr/lib64/libtevent.so.0(+0x8227) [0x7ff0ad467227]
#8 /usr/lib64/libtevent.so.0(_tevent_loop_once+0x8d) [0x7ff0ad46346d]
#9 winbindd(main+0xb7c) [0x55938b4074cc]
#10 /lib64/libc.so.6(__libc_start_main+0xf0) [0x7ff0ace99620]
#11 winbindd(_start+0x29) [0x55938b407b59]
dumping core in /var/log/samba/cores/winbindd
Abgebrochen
main ~ #
This is strange, it seems that it cannot find the AD domain, could you
try changing the nameserver in your /etc/resolv.conf to your Samba AD DC
Rowland
> This is strange, it seems that it cannot find the AD domain, could you
> try changing the nameserver in your /etc/resolv.conf to your Samba AD DC
well, it is that way since near the beginning of the thread:
main ~ # cat /etc/resolv.conf
search arbeitsgruppe.ikw-amstetten.at
nameserver 10.0.0.224
Can I check for specific DNS entries on the DC?
What query is done then, what has to be provided?
thanks, Stefan
maybe by:
leave domain, empty /var/lib/samba, then re-install samba, then re-join?
As mentioned I had tried rm-ing /var/lib/samba already but failed at
joining then because of the missing secrets.tdb (maybe it would have
been enough to touch it, I don't know). I will try.
checked for old or duplicate samba-files, no, that seems OK
> Am 2016-12-31 um 09:37 schrieb Rowland Penny via samba:
>
> > This is strange, it seems that it cannot find the AD domain, could
> > you try changing the nameserver in your /etc/resolv.conf to your
> > Samba AD DC
>
> well, it is that way since near the beginning of the thread:
>
> main ~ # cat /etc/resolv.conf
> search arbeitsgruppe.ikw-amstetten.at
> nameserver 10.0.0.224
>
> Can I check for specific DNS entries on the DC?
> What query is done then, what has to be provided?
>
> thanks, Stefan
>
>
OOPS, sorry I meant:
try changing the nameserver in your /etc/resolv.conf to your other Samba
AD DC
Rowland
> Am 2016-12-30 um 18:31 schrieb Rowland Penny via samba:
> >> remember: server "main" was nt4-pdc ~~ and we only replaced
> >> smb.conf and joined etc etc // maybe too bold? ;-)
> >
> > Oh definitely, you will probably have to empty /var/lib/samba and
> > then let Samba fill it up again.
>
> maybe by:
>
> leave domain, empty /var/lib/samba, then re-install samba, then
> re-join? As mentioned I had tried rm-ing /var/lib/samba already but
> failed at joining then because of the missing secrets.tdb (maybe it
> would have been enough to touch it, I don't know). I will try.
>
> checked for old or duplicate samba-files, no, that seems OK
>
>
>
Samba should recreate the files required, what is the exact command you
are running to join the domain ?
Who owns /var/lib/samba and what are the permissions set to ?
Rowland
> OOPS, sorry I meant:
>
> try changing the nameserver in your /etc/resolv.conf to your other Samba
> AD DC
there is only one Samba AD DC now:
backup.arbeitsgruppe.secret.tld 10.0.0.224
> Samba should recreate the files required, what is the exact command you
> are running to join the domain ?
>
> Who owns /var/lib/samba and what are the permissions set to ?
SOLVED -> what a journey ;-)
rebuilt several packages on the member server today, perl, mit-krb5,
samba etc
But what did the change was the clearing of /var/lib/samba, that seems
to have been the issue since beginning.
I stopped smbd nmbd winbindd
# net ads leave -U Administrator
after successful leave I rm-ed /var/lib/samba (I only left the subdir
private there) then rejoined the ADS domain.
Now winbindd -i -d10 looks very different ;-)
"wbinfo -u" brings users now.
*phew*
Thanks all for the help so far, could have thought of doing so earlier
(well, I did, but did it wrong ...)
I test things now.
Thanks again @ Rowland, Louis, etc
-
Maybe I come back with another issue later, we saw permission problems
at editing GPOs. "sysvolreset" and "sysvolcheck" done OK already.
> Am 2016-12-31 um 12:08 schrieb Rowland Penny via samba:
>
> > Samba should recreate the files required, what is the exact command
> > you are running to join the domain ?
> >
> > Who owns /var/lib/samba and what are the permissions set to ?
>
> SOLVED -> what a journey ;-)
>
> rebuilt several packages on the member server today, perl, mit-krb5,
> samba etc
>
> But what did the change was the clearing of /var/lib/samba, that
> seems to have been the issue since beginning.
>
> I stopped smbd nmbd winbindd
>
> # net ads leave -U Administrator
>
> after successful leave I rm-ed /var/lib/samba (I only left the subdir
> private there) then rejoined the ADS domain.
>
> Now winbindd -i -d10 looks very different ;-)
>
> "wbinfo -u" brings users now.
Next step, does 'getent passwd a_username' show anything ?
>
> *phew*
>
> Thanks all for the help so far, could have thought of doing so
> earlier (well, I did, but did it wrong ...)
>
> I test things now.
>
> Thanks again @ Rowland, Louis, etc
No problem
>
> -
>
> Maybe I come back with another issue later, we saw permission
> problems at editing GPOs. "sysvolreset" and "sysvolcheck" done OK
> already.
>
>
What problem are you having ?
Rowland
>> "wbinfo -u" brings users now.
>
> Next step, does 'getent passwd a_username' show anything ?
yes! On the member server:
main ~ # grep ads1 /etc/passwd
main ~ # getent passwd ads1
ads1:*:13112:10513::/home/ARBEITSGRUPPE/ads1:/bin/false
This is a newly created user in the AD.
As mentioned old users are in /etc/passwd on the member server from the
time when it was the NT4-PDC. I might/should remove them from that file now?
>> Maybe I come back with another issue later, we saw permission
>> problems at editing GPOs. "sysvolreset" and "sysvolcheck" done OK
>> already.
>
> What problem are you having ?
I have to re-test that onsite in the next days, I am currently at home
and have no RSAT-tools at hand. When we edited group policy objects we
got some "access denied", I can't remember the specific "path" now. We
will test that in the next days and I report back.
Aside from that it looks to me as if that migration (NT4 domain -> AD
domain) is pretty much done?
-- have a happy new year everyone!
Stefan
> Am 2016-12-31 um 13:14 schrieb Rowland Penny via samba:
>
> >> "wbinfo -u" brings users now.
> >
> > Next step, does 'getent passwd a_username' show anything ?
>
> yes! On the member server:
>
> main ~ # grep ads1 /etc/passwd
>
> main ~ # getent passwd ads1
> ads1:*:13112:10513::/home/ARBEITSGRUPPE/ads1:/bin/false
Are these the numbers you want to use ?
I ask this because you are using the 'rid' backend, but will probably
also have uidNumber & gidNumber attributes in AD.
>
> This is a newly created user in the AD.
>
> As mentioned old users are in /etc/passwd on the member server from
> the time when it was the NT4-PDC. I might/should remove them from
> that file now?
Oh definitely 'should' ;-)
if you look in /etc/nsswitch.conf, the passwd line will be something
like this:
passwd: compat winbind
This means that /etc/passwd will be checked first and any users found
there will be used instead of from AD, also you should not be able to
create new users in AD if they already exist in /etc/passwd. You only
need users and groups stored in one place and that is AD.
>
> >> Maybe I come back with another issue later, we saw permission
> >> problems at editing GPOs. "sysvolreset" and "sysvolcheck" done OK
> >> already.
> >
> > What problem are you having ?
>
> I have to re-test that onsite in the next days, I am currently at home
> and have no RSAT-tools at hand. When we edited group policy objects we
> got some "access denied", I can't remember the specific "path" now. We
> will test that in the next days and I report back.
You will probably need to give Domain Admins the disk operator
privilege:
net rpc rights grant DOMAIN\\"Domain Admins"
SeDiskOperatorPrivilege -UAdministrator
>
> Aside from that it looks to me as if that migration (NT4 domain -> AD
> domain) is pretty much done?
>
> -- have a happy new year everyone!
>
> Stefan
>
>
May I echo that sentiment, may the new year bring you everything you
wish for .
Rowland
As mentioned before:
"rid" is only chosen because I switched to that while trying to make
things work. No decision made here.
And the numbers: same. Just copy and paste from the wiki, no choice made.
>> As mentioned old users are in /etc/passwd on the member server from
>> the time when it was the NT4-PDC. I might/should remove them from
>> that file now?
>
> Oh definitely 'should' ;-)
>
> if you look in /etc/nsswitch.conf, the passwd line will be something
> like this:
>
> passwd: compat winbind
>
> This means that /etc/passwd will be checked first and any users found
> there will be used instead of from AD, also you should not be able to
> create new users in AD if they already exist in /etc/passwd. You only
> need users and groups stored in one place and that is AD.
So that scares me again. rm-ing users from /etc/passwd will now change
their UIDs because it gets them from winbindd/AD then?
In passwd I have UIDs up from 1000 as usual.
I don't *have* to maintain the old UIDs, the admin there is perfectly
happy if we start over with new ones and just do the initial "chown" and
"chmod" if needed .... they just share one fat share within one group
basically (sounds like overkill, right? ;-) )
> You will probably need to give Domain Admins the disk operator
> privilege:
>
> net rpc rights grant DOMAIN\\"Domain Admins"
> SeDiskOperatorPrivilege -UAdministrator
gives me:
Failed to grant privileges for ARBEITSGRUPPE\Domain Admins
(NT_STATUS_ACCESS_DENIED)
is "rpc" correct here?
> May I echo that sentiment, may the new year bring you everything you
> wish for .
thanks a lot!
> You will probably need to give Domain Admins the disk operator
> privilege:
>
> net rpc rights grant DOMAIN\\"Domain Admins"
> SeDiskOperatorPrivilege -UAdministrator
update: had to run that on the DC, worked.
tests with RSAT tomorrow or so.
Try checking in AD, as you have classicupgraded, your users should have
uidNumber attributes. Find the lowest and the highest, do the same for
groups and if you change to the 'ad' backend and set the range based on
your lowest and highest numbers (remembering you will probably want to
add new users, so add something to the highest number), you should get
the same IDs you had on the PDC. You will have to remove the users
from /etc/passwd though.
The ranges on the wiki were chosen for:
the '*' range starts at 2000 so that it allows for any local Unix users
& groups you may require, it ends at 9999.
The 'DOMAIN' range starts at 10000, this is where ADUC starts from, you
can end it where you like.
The whole idea behind AD is having just one place to maintain users,
so you do not and should not have users in multiple databases.
>
> In passwd I have UIDs up from 1000 as usual.
>
> I don't *have* to maintain the old UIDs, the admin there is perfectly
> happy if we start over with new ones and just do the initial "chown"
> and "chmod" if needed .... they just share one fat share within one
> group basically (sounds like overkill, right? ;-) )
>
You may feel that you need to renumber your users, but this will have
to be your decision, it all boils down to what works for you ;-)
Rowland
> Try checking in AD, as you have classicupgraded, your users should have
> uidNumber attributes. Find the lowest and the highest, do the same for
> groups and if you change to the 'ad' backend and set the range based on
> your lowest and highest numbers (remembering you will probably want to
> add new users, so add something to the highest number), you should get
> the same IDs you had on the PDC. You will have to remove the users
> from /etc/passwd though.
>
> The ranges on the wiki were chosen for:
> the '*' range starts at 2000 so that it allows for any local Unix users
> & groups you may require, it ends at 9999.
> The 'DOMAIN' range starts at 10000, this is where ADUC starts from, you
> can end it where you like.
>
> The whole idea behind AD is having just one place to maintain users,
> so you do not and should not have users in multiple databases.
I was bold now.
rm-ed users from memberserver:/etc/passwd
stopped samba services, edited backend to "ad", restarted
seems to work for me ;-)
same to do on DC, I assume (we run 3 administrative shares there as well)
> Am 2017-01-01 um 13:29 schrieb Rowland Penny via samba:
>
> > Try checking in AD, as you have classicupgraded, your users should
> > have uidNumber attributes. Find the lowest and the highest, do the
> > same for groups and if you change to the 'ad' backend and set the
> > range based on your lowest and highest numbers (remembering you
> > will probably want to add new users, so add something to the
> > highest number), you should get the same IDs you had on the PDC.
> > You will have to remove the users from /etc/passwd though.
> >
> > The ranges on the wiki were chosen for:
> > the '*' range starts at 2000 so that it allows for any local Unix
> > users & groups you may require, it ends at 9999.
> > The 'DOMAIN' range starts at 10000, this is where ADUC starts from,
> > you can end it where you like.
> >
> > The whole idea behind AD is having just one place to maintain users,
> > so you do not and should not have users in multiple databases.
>
> I was bold now.
> rm-ed users from memberserver:/etc/passwd
>
> stopped samba services, edited backend to "ad", restarted
>
> seems to work for me ;-)
Good
>
> same to do on DC, I assume (we run 3 administrative shares there as
> well)
If you are thinking of adding the 'idmap config' lines to the
smb.conf, then don't. On earlier versions of Samba they do nothing, but
from 4.5.0 they cause errors.
If a user has a uidNumber, this will be used on a DC instead of the
xidNumber stored in idmap.ldb, though you may have to run 'net cache
flush'
Rowland
>> same to do on DC, I assume (we run 3 administrative shares there as
>> well)
>
> If you are thinking of adding the 'idmap config' lines to the
> smb.conf, then don't. On earlier versions of Samba they do nothing, but
> from 4.5.0 they cause errors.
> If a user has a uidNumber, this will be used on a DC instead of the
> xidNumber stored in idmap.ldb, though you may have to run 'net cache
> flush'
I wasn't specific enough, I only meant removing users and groups from
/etc/passwd and /etc/group. Nothing in smb.conf
Did so, seems to work so far ;-)
> If a user has a uidNumber, this will be used on a DC instead of the
> xidNumber stored in idmap.ldb, though you may have to run 'net cache
> flush'
"net cache flush" threw me back on the member server now :-(
Maybe I shouldn't have done that, maybe it's good to uncover some hidden
issue(s).
# wbinfo -i sgw
failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
Could not get info for user sgw
# wbinfo -n sgw
S-1-5-21-2777655458-4002997014-749295002-3000 SID_USER (1)
# wbinfo -S S-1-5-21-2777655458-4002997014-749295002-3000
failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
Could not convert sid S-1-5-21-2777655458-4002997014-749295002-3000 to uid
# wbinfo -u | grep sgw
sgw
*scratches head* ... again
> # wbinfo -S S-1-5-21-2777655458-4002997014-749295002-3000
> failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
> Could not convert sid S-1-5-21-2777655458-4002997014-749295002-3000 to uid
-----------------------------------------------------------------^^^^
I think I have my idmap range wrong, correct?
# net ads search '(|(uidNumber=*)(gidNumber=*))' sAMAccountName
uidNumber gidNumber -P | grep uidN | sort -n
... shows me uidNumbers:
uidNumber: 0
uidNumber: 1000
.. up to 1077
So my idmap range was completely wrong, I assume.
I now have on the member server:
# cat /etc/samba/smb.conf
[global]
security = ADS
workgroup = ARBEITSGRUPPE
realm = arbeitsgruppe.secret.tld
log file = /var/log/samba/%m.log
log level = 1
idmap config * : backend = tdb
#idmap config * : range = 2000-2999
## idmap config for the ARBEITSGRUPPE domain
idmap config ARBEITSGRUPPE:backend = ad
idmap config ARBEITSGRUPPE:range = 1000-9999
username map = /etc/samba/user.map
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind refresh tickets = Yes
Now I get wbinfo -i again:
# wbinfo -i sgw
sgw:*:4294967295:4294967295:sgw:/home/ARBEITSGRUPPE/sgw:/bin/false
But the group is wrong.
# wbinfo --group-info 'domain users'
domain users:x:4294967295:
What to correct here, please?
> Am 2017-01-01 um 14:40 schrieb Rowland Penny via samba:
>
> > If a user has a uidNumber, this will be used on a DC instead of the
> > xidNumber stored in idmap.ldb, though you may have to run 'net cache
> > flush'
>
> "net cache flush" threw me back on the member server now :-(
>
> Maybe I shouldn't have done that, maybe it's good to uncover some
> hidden issue(s).
'net cache flush' clears winbind's cache, but this should be refilled
the next time winbind connects to AD.
>
> # wbinfo -i sgw
> failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND
> Could not get info for user sgw
>
> # wbinfo -n sgw
> S-1-5-21-2777655458-4002997014-749295002-3000 SID_USER (1)
>
> # wbinfo -S S-1-5-21-2777655458-4002997014-749295002-3000
> failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
> Could not convert sid S-1-5-21-2777655458-4002997014-749295002-3000
> to uid
>
> # wbinfo -u | grep sgw
> sgw
>
> *scratches head* ... again
>
>
The problem with using wbinfo is, it isn't what the underlying OS uses,
you need to use 'getent' for this.
Just seen you latest post, moving to that
Rowland
>
> googled and tried stuff:
>
> # net ads search '(|(uidNumber=*)(gidNumber=*))' sAMAccountName
> uidNumber gidNumber -P | grep uidN | sort -n
>
> ... shows me uidNumbers:
>
> uidNumber: 0
You definitely shouldn't have a user with the ID of '0' (in my opinion)
Is this Administrator ?
> uidNumber: 1000
>
> .. up to 1077
So it looks like you only have 77 users, but cannot have any local Unix
users because your Unix users start at 1000. How do feel about changing
the uidNumbers ? if so, the easiest way will be to open the AD database
with ldbedit:
ldbedit -e nano -H /usr/local/samba/private/sam.ldb
Then search through the file for 'uidNumber' and then change the
contents, I would just add a '0' after the first digit i.e. '1077'
would become '10077'
Remove the uidNumber that contains '0'
check that Domain Users has a gidNumber attribute and that it contains
a number in the 10000 range
finally change 'idmap config ARBEITSGRUPPE:range = 1000-9999' to 'idmap
config ARBEITSGRUPPE:range = 10000-99999' and put the 'idmap config
SAMDOM : schema_mode = rfc2307' line back.
restart the Samba deamons, run 'net cache flush' again then run 'getent
passwd sgw'
What is in the 'user.map' ?
Rowland
> So it looks like you only have 77 users, but cannot have any local Unix
> users because your Unix users start at 1000. How do feel about changing
> the uidNumbers ?
feels scary and I'd like to avoid that :-)
> if so, the easiest way will be to open the AD database
> with ldbedit:
>
> ldbedit -e nano -H /usr/local/samba/private/sam.ldb
>
> Then search through the file for 'uidNumber' and then change the
> contents, I would just add a '0' after the first digit i.e. '1077'
> would become '10077'
And that won't break things??
> Remove the uidNumber that contains '0'
I just have a look via ldbedit, yes, that points to:
distinguishedName: CN=root,CN=Users,DC=arbeitsgruppe,......
> check that Domain Users has a gidNumber attribute and that it contains
> a number in the 10000 range
I doesn't have that attribute as far as I see.
Do i just add that line?
> finally change 'idmap config ARBEITSGRUPPE:range = 1000-9999' to 'idmap
> config ARBEITSGRUPPE:range = 10000-99999' and put the 'idmap config
> SAMDOM : schema_mode = rfc2307' line back.
>
> restart the Samba deamons, run 'net cache flush' again then run 'getent
> passwd sgw'
Feeling like a blind brain surgeon already ;-)
I have to prepare myself mentally :-)
>> But the group is wrong.
>>
>> # wbinfo --group-info 'domain users'
>> domain users:x:4294967295:
>>
>> What to correct here, please?
>>
>>
>
> What is in the 'user.map' ?
I followed
# cat user.map
!root = ARBEITSGRUPPE\Administrator
all uidNumber now > 10000
except that "root", I was unsure now (?)
gidNumber:
# ldbsearch -H /var/lib/samba/private/sam.ldb cn=Domain\ Users | grep
'gidNumber'
gidNumber: 10001
-
smb.conf on member:
idmap config * : backend = tdb
idmap config * : range = 2000-2999
idmap config ARBEITSGRUPPE:backend = ad
idmap config ARBEITSGRUPPE:range = 10000-99999
idmap config ARBEITSGRUPPE:schema_mode = rfc2307
username map = /etc/samba/user.map
winbind enum users = Yes
winbind enum groups = Yes
winbind use default domain = Yes
winbind refresh tickets = Yes
-
restarted all samba daemons on DC and member server, flushed cache
On DC:
# wbinfo -i sgw
sgw:*:10000:10001::/home/ARBEITSGRUPPE/sgw:/bin/false
# getent passwd sgw
sgw:*:10000:10001::/home/ARBEITSGRUPPE/sgw:/bin/false
(good, afaik)
On member server:# wbinfo -i sgw
sgw:*:10000:10001:sgw:/home/ARBEITSGRUPPE/sgw:/bin/false
main samba # getent passwd sgw
sgw:*:10000:10001:sgw:/home/ARBEITSGRUPPE/sgw:/bin/false
- nice, correct??
I even did an additional change and set the gidNumber to 10513 to match
the former gid (in the shared directory the group-id was 10513, now it
is displayed as "domain users" as well).
so now I have:
# getent passwd sgw
sgw:*:10000:10513:sgw:/home/ARBEITSGRUPPE/sgw:/bin/false
*phew*
Any idea what else might be missing? ;-)
thanks!
OK, I am taking this off list ;-)
What you have to understand is that Windows and Unix do things
differently.
Windows uses SID-RID to identify users, group and computers, from your
posts you have a user with the SID-RID of
S-1-5-21-2777655458-4002997014-749295002-3000
The SID is S-1-5-21-2777655458-4002997014-749295002 and most things in
the domain will use this because it identifies the domain, I say most
things, because there are entities known as 'well known SIDs', see here:
https://support.microsoft.com/en-us/kb/243330
They (mostly) don't have RIDs
Windows identifies your users, groups and computers etc by the RID,
this a unique number. This along with the SID is meaningless to Unix.
Unix just uses a number and without the domain name, there is no way to
identify what machine it is from, there is no concept of SID with Unix.
This is where Samba comes in, it provides a bridge between Windows and
Unix on AD (and standalone servers, but that is a different subject
and has nothing to do with what we are discussing)
When you create a Windows user in a domain (and even a standalone
windows computer is a domain, its own domain) it is given the same RID
as every user in domain and a unique RID, going back to the SID-RID
shown earlier, this is '3000'. No other entity in the domain will get
the same RID, from what you posted earlier, I believe this is user
'sgw'.
To make the user 'sgw' visible on a domain joined Unix domain member
using the 'ad' winbind backend, a few things have to be set. At a
minimum 'sgw' must have a uidNumber attribute containing a unique
number, Domain Users must have a gidNumber attribute containing a
number and these two numbers must be inside the domain range set in
smb.conf on the domain member.
What complicates the problem is that Samba AD DCs work differently from
Samba domain members. On a DC, as standard, users and groups are mapped
from Windows users to Unix users in idmap.ldb, they all get numbers in
the '3000000' range, but can be changed by adding uidNumber and
gidNumber attributes, no other modifications need to be done to
smb.conf.
On a domain member, you need to use winbind and set it up accordingly.
There are various winbind backends but the two main ones are 'rid' and
'ad'. If you use the 'rid' backend, you do not need to change anything
in AD, the UIDs & GIDs will be calculated from the entities RID.
If you want to use the 'ad' backend, you will need to add uidNumbers to
users and a gidNumber to Domain Users.
I hope you can see from this that changing the contents of uidNumber,
will have no affect to how Windows works.
Any questions, please ask ;-)
Rowland
>
> ok, edited etc
>
> all uidNumber now > 10000
>
> except that "root", I was unsure now (?)
If you have a user called 'root', then it is easy, remove it, 'root'
shouldn't exist in AD, it is a Unix only user and you need to map
Administrator to 'root' in the user.map
Looking good
>
> I even did an additional change and set the gidNumber to 10513 to
> match the former gid (in the shared directory the group-id was 10513,
> now it is displayed as "domain users" as well).
>
> so now I have:
>
> # getent passwd sgw
> sgw:*:10000:10513:sgw:/home/ARBEITSGRUPPE/sgw:/bin/false
>
> *phew*
>
> Any idea what else might be missing? ;-)
>
> thanks!
>
>
The only thing is, do any of your users need to actually login into the
domain member ?
If so, this is where using the 'ad' backend comes into its own, you
just need to add 'loginshell' and 'unixHomeDirectory' attributes
to the required users i.e.
loginshell: /bin/bash
unixHomeDirectory: /home/sgw
Rowland
> If you have a user called 'root', then it is easy, remove it, 'root'
> shouldn't exist in AD, it is a Unix only user and you need to map
> Administrator to 'root' in the user.map
removed from AD now.
the user.map was there already, as mentioned.
> The only thing is, do any of your users need to actually login into the
> domain member ?
not really
> If so, this is where using the 'ad' backend comes into its own, you
> just need to add 'loginshell' and 'unixHomeDirectory' attributes
> to the required users i.e.
>
> loginshell: /bin/bash
> unixHomeDirectory: /home/sgw
both attributes are there already, but in getent I get /bin/false
# getent passwd sgw
sgw:*:10000:10513::/home/ARBEITSGRUPPE/sgw:/bin/false
that is optional, but nice to know, sure!
> both attributes are there already, but in getent I get /bin/false
>
> # getent passwd sgw
> sgw:*:10000:10513::/home/ARBEITSGRUPPE/sgw:/bin/false
>
> that is optional, but nice to know, sure!
added
winbind nss info = rfc2307
on the member server. Looks better now.
> Am 2017-01-01 um 17:50 schrieb Stefan G. Weichinger via samba:
>
> > both attributes are there already, but in getent I get /bin/false
> >
> > # getent passwd sgw
> > sgw:*:10000:10513::/home/ARBEITSGRUPPE/sgw:/bin/false
> >
> > that is optional, but nice to know, sure!
>
> added
>
> winbind nss info = rfc2307
>
> on the member server. Looks better now.
>
ah, yes, without that you were using 'winbind nss info = template' and
that doesn't get the loginshell and unixhomedirectory attributes.
Rowland