I did installed Samba 3.0.24 (first time: debian package, second time: self compiled -> both with same issue):
wbinfo -u ,-t ,-g OK!
net ads join OK !
ldapsearch to AD shows all correctly. All parameters are available.
getent passwd: only files, not the winbind result.
getent group: files and the AD Groups with Unix gids, but without the members.
passwd: files winbind
workgroup = IPR-OFFICE
realm = IPR.UNI-KARLSRUHE.DE
server string = %h server (Samba %v)
netbios name = i60p311
wins server = i60pdc
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
log level = 10
syslog = 0
panic action = /usr/share/samba/panic-action %d
security = ADS
encrypt passwords = true
password server = i60pdc.ipr.uni-karlsruhe.de
passdb backend = tdbsam
obey pam restrictions = yes
invalid users = root
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\sUNIX\spassword:* %n\n *Retype\snew\sUNIX\spassword:* %n\n .
socket options = TCP_NODELAY
winbind separator = /
winbind enum users = yes
winbind enum groups = yes
winbind cache time = 3600
idmap backend = ad
#idmap backend = idmap_rid:BUILTIN=10000-10999,IPR-OFFICE=110000-1000000
#idmap backend = rid:IPR-OFFICE=500-10000
idmap uid = 6000-27000 #our unix id ranges, not in conflict with etc/passwd
idmap gid = 600-619
#idmap uid = 30000-40000
#idmap gid = 30000-40000
template shell = /bin/andysh
winbind use default domain = yes
#clients channel = no
#winbind refresh tickets = yes
#idmap backend = rid:IPR-OFFICE=25200-100000
#allow trusted domains = yes
winbind nss info = rfc2307
Created attachment 2679 [details]
Created attachment 2680 [details]
net idmap dump /var/lib/samba/winbindd_idmap.tdb looks very good !
From the log:
ad_idmap_get_id_from_sid: ads_pull_uint32: could not read attribute 'gidNumber'
So your primary windows group (Domain Users) does not have a posix mapping attribute yet. Can you add one and retry?
I did the following tasks since my last Comment:
I added a GroupID to the "Domain-User" with RID 513 Standard AD entry.
The result is know that "getent passwd" prints out the Users to the stdout, but with GID from this "Domain-Users".
This is a little success since my last tasks!
But i added an own group only for Unix Clients to the AD and would like only to work with this group, not the Standard Windows Groups. I gave them a GID and this is also shown in "getent group", but without its members which i added in the AD Configuration to this Unix Group. The Unix Group SID->GID also shown correctly by the "net idmap dump ....". Die memberUid in the Unix Group is correctly shown by "ldapsearch...". -> Courious behavior.
Do i have to give ALL Windows AD Groups and Users a UID/GID, independent if the Windows AD Groups (Standard or own created) are used on Unix Clients or not used on Unix Clients ????
The part....."i cant see the members of the Unix Group which i added in AD to the Unix Group" could be canceled.
I saw that the members have to be added "windows side" and "unix side" (below the TAB "Unix Attributes" in the group configuration).
This means each member habe to be added twice.
Now, there is only the issue winbind asks to "Domain USer" RID 513 Group. Is there workaround.
For example changing the primary group ?
iam able to map user/groups, to add user to groups, to change primary group in AD.
Winbind with idmap backend=ad works.
But an ls -al or sometimes pam_winbind ist very slow. A samba developer told me this is a known performance problem in method of listing users and groups with winbind. This problem is beeing fixed in the moment and would be expectly solved in version 3.0.26
(In reply to comment #6)
> Now, there is only the issue winbind asks to "Domain USer" RID 513 Group. Is
> there workaround.
> For example changing the primary group ?
Sure, you can just modify the primary group to a group that has POSIX attributes.
(In reply to comment #7)
> But an ls -al or sometimes pam_winbind ist very slow. A samba developer told me
> this is a known performance problem in method of listing users and groups with
> winbind. This problem is beeing fixed in the moment and would be expectly
> solved in version 3.0.26
Verify your system can correctly find the AD dc (in DNS terms), for the slowliness of ls: try to use nscd.