Re: [Samba] Samba4 LDAP ACLs - access to POSIX attributes from a non-admin account

[Rob McCorkell]

Sorry for the late reply - was running it through testing in our 
environment. But so far it seems to be working a treat! Thanks for this, 
much appreciated.


Rob

On 15/12/12 16:42, Thomas Simmons wrote:

Hello Rob,

You can enable anonymous binding to AD by creating the attribute 
"dsHeuristics" with a value of "002001001" under the DN:

CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration

The Microsoft instructions mention below mention using the ADSI Edit 
tool on Windows, but it can be done with any LDAP editing tool. I just 
tested this on S4 and it appears to work.


See: http://technet.microsoft.com/en-us/library/cc816788(v=ws.10).aspx 





--
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] Samba 4, Winbind & RFC2307

[TAKAHASHI Motonobu]

From: Thomas Simmons 
Date: Sat, 15 Dec 2012 22:11:00 -0500

> After provisioning a domain (with rfc2307 attributes), what are the next
> steps to enable S4 winbind to use these attributes?

As far as I know, winbind on S4 DC cannot use this attribute. This setting
affects only S4 domain member.

You may manually set these attributes on S4 DC with the script:
  http://lists.samba.org/archive/samba-technical/2012-November/089119.html

---
TAKAHASHI Motonobu 
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] Samba 4, Winbind & RFC2307

[Thomas Simmons]

Hello Takahashi,

I am using ADUC to manage UNIX attributes and have created the attributes
for each test user.

Just to make sure I understand you correctly; you're saying there is no way
to have S4 winbind use rfc2307 attributes for *nix authentication on a DC,
but it will work on a member server? This is a "clean" provision test setup
that I am running at home. In production (and testing at work) I will be
performing a classicupgrade. I have 300+ users with existing accounts
spread out across many servers. S3 (or it's LDAP backend) is used for auth
& auth on all of our services, so I need to ensure these attributes stay
the same. Worst case I can use NSS+LDAP, but I would prefer to use winbind
if possible.

Here I have NSS+LDAP configured and getent reports the correct uidNumber
and gidNumber that I have specified in AD (rfc2307 attributes):

root@ALW1:~# getent passwd | grep tuser
tuser1:*:10005:1:Test User1:/home/tuser1:/bin/sh
tuser2:*:10006:1:Test User2:/home/tuser2:/bin/sh
tuser3:*:10007:1:Test User3:/home/tuser3:/bin/sh

Here (DC) I am using winbind for authentication, and getent does not report
the correct uidNumber and gidNumber:

[root@ADC1 ~]# getent passwd | grep tuser
TESTDOM\tuser1:*:325:100:Test User1:/home/tuser1:/bin/sh
TESTDOM\tuser2:*:326:100:Test User2:/home/tuser2:/bin/sh
TESTDOM\tuser3:*:327:100:Test User3:/home/tuser3:/bin/sh








On Sun, Dec 16, 2012 at 9:57 AM, TAKAHASHI Motonobu  wrote:

> From: Thomas Simmons 
> Date: Sat, 15 Dec 2012 22:11:00 -0500
>
> > After provisioning a domain (with rfc2307 attributes), what are the next
> > steps to enable S4 winbind to use these attributes?
>
> As far as I know, winbind on S4 DC cannot use this attribute. This setting
> affects only S4 domain member.
>
> You may manually set these attributes on S4 DC with the script:
>   http://lists.samba.org/archive/samba-technical/2012-November/089119.html
>
> ---
> TAKAHASHI Motonobu 
>
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] Difference between real and reported disk usage

[Berni Ced]

Hi Bjoern and thank you for your reply.

Bjoern Baumbach  sernet.de> writes:
> This is by design.
> With the strict allocate = yes Samba stops creating sparse files. If you
> copy a sparse file with a real size of e.g. 100MB and a
> reserved/allocated size of 1GB to a server with "strict allocate = yes",
> the server writes 900MB trailing zeros to the file 

Ok, ok, but from a user perspective i'm still not sure that there isn't
a bug somewhere. I try to concisely explain my points:

1) smb.conf man page doesn't mention that space allocation could bring
to a file larger than its effective size. Rather, the man page say:
---
When this is set to yes the server will change from UNIX behaviour of
not committing real disk storage blocks when a file is extended to the
Windows behaviour of actually forcing the disk system to allocate real
storage blocks when a file is created or extended to be a given size.
---
The key concept is "allocate *real* storage blocks".
I thought that Samba, by default, can optimize the space allocated,
using the sparse file feature to make some file occupy less space than
what is really needed. It was really a surprise when i get "no space
left on device" copying 45 GB of data on a 210 GB partition!

2) From smb.conf man page i've interpreted that if you use an extent
based filesystem like ext4 or xfs, "strict allocate = yes" is something
good, recommended, with many merit and apparently no big defects.

3) The behaviour is not (as can be guessed) the same with every clients.
This is because every client can have different space allocation policy
but also because, mmh, there can be a bug or something not handled
somewhere?
For example, i've analized the data copied with strict allocation
activated and i've found that Windows Server 2008 make files space
allocation in 1024 kiB blocks. This means that if you copy 1025 kiB,
that file will effectively occupy 2048 kiB. To be more precise the real
file occupation is a little (4 byte) more, but i think it's due to
linux filesystem overhead like extended attributes. But if i repeat the
same file copy from Windows 2000 Pro, i get no space overhead and the
file space results are the same obtained without strict allocate.
It could be interesting to know with Windows 7 or 8...
Maybe it's something that samba could manage to avoid the reported
overhead?

4) Even if it resolves some problems (i've heard with quota), how can
someone plan the samba share size or manage its free space if the
space allocation is such not predictable. The administrator have to
know every possible client that can and will connect to its samba
share. In other words, the more the environments is heterogeneous, the
worst.


If someone wants to do some test, can follow these steps:
1) Create a 1 MB file:
   dd if=/dev/urandom of=001M.txt bs=1024k count=1
2) Create a 1 MB + 1 kB:
   dd if=/dev/urandom of=001M1k.txt bs=1025k count=1
3) Repeat steps 1-2 creating 2MB, 3MB, 10MB and 2M+1k, 3M+1k, 10M+1k.
4) Copy the files on a Windows system of your choice.
5) Prepare a samba share configured with "strict allocate = yes":
6) Copy the file created before to the samba share using Windows.
7) Check the real file occupation with "ls -lks" or "du -s".

Cesare.


-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] Samba 4, Winbind & RFC2307

[Andrew Bartlett]

On Sun, 2012-12-16 at 12:23 -0500, Thomas Simmons wrote:
> Hello Takahashi,
> 
> I am using ADUC to manage UNIX attributes and have created the attributes
> for each test user.
> 
> Just to make sure I understand you correctly; you're saying there is no way
> to have S4 winbind use rfc2307 attributes for *nix authentication on a DC,
> but it will work on a member server? This is a "clean" provision test setup
> that I am running at home. In production (and testing at work) I will be
> performing a classicupgrade. I have 300+ users with existing accounts
> spread out across many servers. S3 (or it's LDAP backend) is used for auth
> & auth on all of our services, so I need to ensure these attributes stay
> the same. Worst case I can use NSS+LDAP, but I would prefer to use winbind
> if possible.
> 
> Here I have NSS+LDAP configured and getent reports the correct uidNumber
> and gidNumber that I have specified in AD (rfc2307 attributes):
> 
> root@ALW1:~# getent passwd | grep tuser
> tuser1:*:10005:1:Test User1:/home/tuser1:/bin/sh
> tuser2:*:10006:1:Test User2:/home/tuser2:/bin/sh
> tuser3:*:10007:1:Test User3:/home/tuser3:/bin/sh
> 
> Here (DC) I am using winbind for authentication, and getent does not report
> the correct uidNumber and gidNumber:
> 
> [root@ADC1 ~]# getent passwd | grep tuser
> TESTDOM\tuser1:*:325:100:Test User1:/home/tuser1:/bin/sh
> TESTDOM\tuser2:*:326:100:Test User2:/home/tuser2:/bin/sh
> TESTDOM\tuser3:*:327:100:Test User3:/home/tuser3:/bin/sh

On the DC, set:

idmap_ldb:use rfc2307=yes

We realise that having the different behaviour between the DC and the
member server is very annoying, but we have not had the resources to
rework this area of the codebase quite yet.

Andrew Bartlett

-- 
Andrew Bartletthttp://samba.org/~abartlet/
Authentication Developer, Samba Team   http://samba.org


-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] Samba4 LDAP ACLs - access to POSIX attributes from a non-admin account

[Andrew Bartlett]

On Fri, 2012-12-14 at 18:03 +, Rob McCorkell wrote:
> In our current testing environment, we are using nslcd to get user and 
> group information from the Samba4 LDAP server, using the last part of 
> objectSid as uidNumber. The configuration is designed to pull down 
> unixHomeDirectory and loginShell if they exist, but they default to 
> standard values if they do not. nslcd on each machine binds to LDAP 
> using a dedicated user account, nslcd-service, and the entire setup 
> works pretty well.
> 
> But now we have run into a problem - although both POSIX attributes 
> exists on a particular user (ismith in this case) they cannot be read by 
> the machine using nslcd-service to bind to the LDAP directory. After 
> further testing, we found that binding as Administrator makes the 
> attributes show up - in fact adding nslcd-service to 'Domain Admins' 
> group also lets it see those attributes. Unfortunately both of these 
> options are a huge security risk - any server that becomes compromised 
> can effectively take control of the Samba4 domain and server, and in 
> turn take out the rest of the network.
> 
> It seems strange that all normal attributes are perfectly readable by 
> any user, while the manually added POSIX attributes are not. 

Indeed, it is very strange, but sadly we didn't notice this in the
testing prior to Samba 4.0.  We recently (for the protection of users in
existing domains who may have restrictive READ ACLs set prior to
migration) enabled enforcement of ACLs for all operations, not just
writes.

To disable this, and go back to the ACL behaviour we had on rc5, set:

acl:read=false

in your smb.conf.

This will mean that all users can read all attributes, unless they are
passwords or marked confidential in the schema.

We are sorry for this regression, and hope to sort it out soon (but I
think soon means after Christmas at this point, as many of us are taking
a bit of time to recover after the massive effort to get 4.0 out the
door). 

Sorry,

Andrew Bartlett

-- 
Andrew Bartletthttp://samba.org/~abartlet/
Authentication Developer, Samba Team   http://samba.org


-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] Samba 4, Winbind & RFC2307

[Thomas Simmons]

Hello Andrew,

If functionality is not there, I certainly understand and can work around
it. I just want to make sure I am not misunderstanding something.

When you say I should set "idmap_ldb:use rfc2307=yes" in smb.conf on the
DC, do you mean that by doing so I can use winbind (and the rfc2307
attributes) for *nix authentication on the DC? I am confused because I
already have "idmap_ldb:use rfc2307 = yes" in my smb.conf (it gets added
automatically with the classicupgrade and I always provision my "clean"
test setup with "--use-rfc2307"). That actually works fine - the rfc2307
attributes are there and I can modify them in ADUC. If I configure the
server to use NSS+LDAP for authentication, my users's uid number, gid
number, shell, etc are what I have specified in ADUC. When I try using
winbind, it is not using the rfc2307 information from AD. Initially,
 "idmap_ldb:use rfc2307 = yes" was the only idmap related entry in my
smb.conf. When that did not work I tried a bunch of other "idmap config
DOMAIN" settings.

Again, if this simply does not work at this time, I can use NSS and LDAP
for logins on my DCs. With my S3 setup, I've always used LDAP for auth on
*nix systems and am not terribly familiar with winbind, so I just want to
make sure I'm not missing something. My next test will be setting up a
member server. Can you tell me what entries I will need in my smb.conf to
have winbind use the rfc2307 information from my S4 DC on member servers?

Thank you for your help!


On Sun, Dec 16, 2012 at 4:04 PM, Andrew Bartlett  wrote:

> On Sun, 2012-12-16 at 12:23 -0500, Thomas Simmons wrote:
> > Hello Takahashi,
> >
> > I am using ADUC to manage UNIX attributes and have created the attributes
> > for each test user.
> >
> > Just to make sure I understand you correctly; you're saying there is no
> way
> > to have S4 winbind use rfc2307 attributes for *nix authentication on a
> DC,
> > but it will work on a member server? This is a "clean" provision test
> setup
> > that I am running at home. In production (and testing at work) I will be
> > performing a classicupgrade. I have 300+ users with existing accounts
> > spread out across many servers. S3 (or it's LDAP backend) is used for
> auth
> > & auth on all of our services, so I need to ensure these attributes stay
> > the same. Worst case I can use NSS+LDAP, but I would prefer to use
> winbind
> > if possible.
> >
> > Here I have NSS+LDAP configured and getent reports the correct uidNumber
> > and gidNumber that I have specified in AD (rfc2307 attributes):
> >
> > root@ALW1:~# getent passwd | grep tuser
> > tuser1:*:10005:1:Test User1:/home/tuser1:/bin/sh
> > tuser2:*:10006:1:Test User2:/home/tuser2:/bin/sh
> > tuser3:*:10007:1:Test User3:/home/tuser3:/bin/sh
> >
> > Here (DC) I am using winbind for authentication, and getent does not
> report
> > the correct uidNumber and gidNumber:
> >
> > [root@ADC1 ~]# getent passwd | grep tuser
> > TESTDOM\tuser1:*:325:100:Test User1:/home/tuser1:/bin/sh
> > TESTDOM\tuser2:*:326:100:Test User2:/home/tuser2:/bin/sh
> > TESTDOM\tuser3:*:327:100:Test User3:/home/tuser3:/bin/sh
>
> On the DC, set:
>
> idmap_ldb:use rfc2307=yes
>
> We realise that having the different behaviour between the DC and the
> member server is very annoying, but we have not had the resources to
> rework this area of the codebase quite yet.
>
> Andrew Bartlett
>
> --
> Andrew Bartletthttp://samba.org/~abartlet/
> Authentication Developer, Samba Team   http://samba.org
>
>
>
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] Samba 4, Winbind & RFC2307

[Andrew Bartlett]

On Sun, 2012-12-16 at 16:51 -0500, Thomas Simmons wrote:
> Hello Andrew,
> 
> 
> If functionality is not there, I certainly understand and can work
> around it. I just want to make sure I am not misunderstanding
> something.
> 
> 
> When you say I should set "idmap_ldb:use rfc2307=yes" in smb.conf on
> the DC, do you mean that by doing so I can use winbind (and the
> rfc2307 attributes) for *nix authentication on the DC? I am confused
> because I already have "idmap_ldb:use rfc2307 = yes" in my smb.conf
> (it gets added automatically with the classicupgrade and I always
> provision my "clean" test setup with "--use-rfc2307"). That actually
> works fine - the rfc2307 attributes are there and I can modify them in
> ADUC. If I configure the server to use NSS+LDAP for authentication, my
> users's uid number, gid number, shell, etc are what I have specified
> in ADUC. When I try using winbind, it is not using the rfc2307
> information from AD. 

That's odd, but remember that only the UID and GID values will be used
(not the shell or homedir, which is handled in a different bit of the
code).  However, your output below clearly shows that isn't
happening :-(

> > Here I have NSS+LDAP configured and getent reports the
correct uidNumber
> > and gidNumber that I have specified in AD (rfc2307
attributes):
> >
> > root@ALW1:~# getent passwd | grep tuser
> > tuser1:*:10005:1:Test User1:/home/tuser1:/bin/sh
> > tuser2:*:10006:1:Test User2:/home/tuser2:/bin/sh
> > tuser3:*:10007:1:Test User3:/home/tuser3:/bin/sh
> >
> > Here (DC) I am using winbind for authentication, and getent
does not report
> > the correct uidNumber and gidNumber:
> >
> > [root@ADC1 ~]# getent passwd | grep tuser
> > TESTDOM\tuser1:*:325:100:Test User1:/home/tuser1:/bin/sh
> > TESTDOM\tuser2:*:326:100:Test User2:/home/tuser2:/bin/sh
> > TESTDOM\tuser3:*:327:100:Test User3:/home/tuser3:/bin/sh
> 
As a test, can you set 'acl:search=false' and see if it makes a
difference?

> Initially,  "idmap_ldb:use rfc2307 = yes" was the only idmap related
> entry in my smb.conf. When that did not work I tried a bunch of other
> "idmap config DOMAIN" settings. 

The code that handles that isn't hooked up yet.  I'm hoping someone will
take this on for 4.1. 

> Again, if this simply does not work at this time, I can use NSS and
> LDAP for logins on my DCs. With my S3 setup, I've always used LDAP for
> auth on *nix systems and am not terribly familiar with winbind, so I
> just want to make sure I'm not missing something. My next test will be
> setting up a member server. Can you tell me what entries I will need
> in my smb.conf to have winbind use the rfc2307 information from my S4
> DC on member servers?

I don't recall the exact settings right now, but for member servers it
is the same as for a Windows AD domain (yes, I think this should be more
automatic). 

In terms of using nss_ldap on the DC, the only concern I have is that
the [homes] share might not work if you do that.  Our DC code mostly
avoids calling into nss, but that particular area does do it, and really
does expect that nss_winbind is being used. 

For that reason, we generally suggest separation between the DC and
other roles as the best way out of this situation. 

Andrew Bartlett

-- 
Andrew Bartletthttp://samba.org/~abartlet/
Authentication Developer, Samba Team   http://samba.org


-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] logon Samba workstation domain with Active Directory trustdom account issue

[Romain]

Hi,

Did somebody already make a two-way trust relationship between Samba 3 and
AD ?

When I try to access to Samba share with AD account, I've got this:

[2012/12/16 23:00:26.146090,  5] auth/auth.c:268(check_ntlm_password)
  check_ntlm_password: winbind authentication for user [tata] FAILED
with error NT_STATUS_NO_SUCH_USER
[2012/12/16 23:00:26.146123,  2] auth/auth.c:314(check_ntlm_password)
  check_ntlm_password:  Authentication for user [tata] -> [tata]
FAILED with error NT_STATUS_NO_SUCH_USER

but trust domain seems to be ok:

Trusted domains list:

ES01S-1-5-21-1816646249-803782145-3669927669

Trusting domains list:

ES01S-1-5-21-1816646249-803782145-3669927669

and when I try to access samba share with the Administrator account that I
create both side with same passwd, I've got this:

[2012/12/16 22:57:22.701841, 1]
rpc_server/srv_pipe_hnd.c:1602(serverinfo_to_SamInfo_base)
_netr_LogonSamLogon: user ES01\Administrator has user sid
S-1-5-21-1816646249-803782145-3669927669-500 but group sid
S-1-5-21-3405883886-2425668597-4100599511-513. The conflicting domain
portions are not supported for NETLOGON calls

and winfo doesn't seem to work, it should list all trusted users, no ?

# wbinfo -u root nobody smb3user administrator


Regards,
Romain


2012/12/15 Romain 

> Hello list,
>
> Sorry to top again but do we need Kerberos on Samba server to make this
> work ?
>
> Regards,
>
>
> 2012/12/14 Romain 
>
>> Hi,
>>
>> I made a mistake, we have Samba 3.5.3.
>>
>> Can somebody help ?
>>
>> Regards,
>> Romain
>>
>>
>> 2012/12/13 Romain 
>>
>>> Hello samba list,
>>>
>>> I'm close to be able to make this work but I just need a bit help. Here
>>> is the situation:
>>>
>>> - Windows 2008 R2 x64 Domain Controller: domain ES01
>>>
>>> - Samba 3.4.3 Domain Controller:domain ES02
>>>
>>> - Windows Seven Workstation (SSO4): on domain ES02
>>>
>>> - Window Xp Workstation (SSO2): on domain ES01
>>>
>>> We put a both side trust relationship and seems to work regarding
>>> command "net rpc trustdom list".
>>>
>>> *[root@localhost ~]# net rpc trustdom list*
>>> *Enter root's password:*
>>> *Trusted domains list:*
>>> *
>>> *
>>> *ES01S-1-5-21-1816646249-803782145-3669927669*
>>> *
>>> *
>>> *Trusting domains list:*
>>> *
>>> *
>>> *ES01S-1-5-21-1816646249-803782145-3669927669*
>>>
>>>
>>> Now, here is the issue:
>>>
>>> We can logon domain ES01 with Windows account from Windows Xp
>>> Workstation (normal use)
>>> We can logon domain ES01 with Samba account from Windows Xp Workstation
>>> (that's outgoing trust relationship's work)
>>> We can logon domain ES02 with samba account (pretty normal use)
>>> *We CAN'T logon domain ES02 with Windows Account (and unfortunatly,
>>> that's what we need to go further)*
>>>
>>> I join you all my configuration files and SS4 workstation log while I
>>> try to log with "tata" account from ES01 windows domain.
>>>
>>> As you can see in smb.conf, we tried some custom tricks to make winbind
>>> working...
>>>
>>> Hope you will give us a fresh idea that we didn't think about.
>>>
>>> Regards,
>>> Romain
>>>
>>
>>
>
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] Samba 4, Winbind & RFC2307

[Thomas Simmons]

I am using 'template homedir' and 'template shell' for these attributes,
which I'm fine with. It's the uidNumber and gidNumber that
I'm primarily concerned with. My global section:

[global]
workgroup = TESTDOM
realm = internal.testdom.com
netbios name = ADC1
server role = active directory domain controller
dns forwarder = 10.10.65.1
idmap_ldb:use rfc2307 = yes
#acl:search = false

template homedir = /home/%ACCOUNTNAME%
template shell = /bin/sh



On Sun, Dec 16, 2012 at 5:06 PM, Andrew Bartlett  wrote:

> On Sun, 2012-12-16 at 16:51 -0500, Thomas Simmons wrote:
> > Hello Andrew,
> >
> >
> > If functionality is not there, I certainly understand and can work
> > around it. I just want to make sure I am not misunderstanding
> > something.
> >
> >
> > When you say I should set "idmap_ldb:use rfc2307=yes" in smb.conf on
> > the DC, do you mean that by doing so I can use winbind (and the
> > rfc2307 attributes) for *nix authentication on the DC? I am confused
> > because I already have "idmap_ldb:use rfc2307 = yes" in my smb.conf
> > (it gets added automatically with the classicupgrade and I always
> > provision my "clean" test setup with "--use-rfc2307"). That actually
> > works fine - the rfc2307 attributes are there and I can modify them in
> > ADUC. If I configure the server to use NSS+LDAP for authentication, my
> > users's uid number, gid number, shell, etc are what I have specified
> > in ADUC. When I try using winbind, it is not using the rfc2307
> > information from AD.
>
> That's odd, but remember that only the UID and GID values will be used
> (not the shell or homedir, which is handled in a different bit of the
> code).  However, your output below clearly shows that isn't
> happening :-(
>
> > > Here I have NSS+LDAP configured and getent reports the
> correct uidNumber
> > > and gidNumber that I have specified in AD (rfc2307
> attributes):
> > >
> > > root@ALW1:~# getent passwd | grep tuser
> > > tuser1:*:10005:1:Test User1:/home/tuser1:/bin/sh
> > > tuser2:*:10006:1:Test User2:/home/tuser2:/bin/sh
> > > tuser3:*:10007:1:Test User3:/home/tuser3:/bin/sh
> > >
> > > Here (DC) I am using winbind for authentication, and getent
> does not report
> > > the correct uidNumber and gidNumber:
> > >
> > > [root@ADC1 ~]# getent passwd | grep tuser
> > > TESTDOM\tuser1:*:325:100:Test User1:/home/tuser1:/bin/sh
> > > TESTDOM\tuser2:*:326:100:Test User2:/home/tuser2:/bin/sh
> > > TESTDOM\tuser3:*:327:100:Test User3:/home/tuser3:/bin/sh
> >
> As a test, can you set 'acl:search=false' and see if it makes a
> difference?
>
> > Initially,  "idmap_ldb:use rfc2307 = yes" was the only idmap related
> > entry in my smb.conf. When that did not work I tried a bunch of other
> > "idmap config DOMAIN" settings.
>
> The code that handles that isn't hooked up yet.  I'm hoping someone will
> take this on for 4.1.
>
> > Again, if this simply does not work at this time, I can use NSS and
> > LDAP for logins on my DCs. With my S3 setup, I've always used LDAP for
> > auth on *nix systems and am not terribly familiar with winbind, so I
> > just want to make sure I'm not missing something. My next test will be
> > setting up a member server. Can you tell me what entries I will need
> > in my smb.conf to have winbind use the rfc2307 information from my S4
> > DC on member servers?
>
> I don't recall the exact settings right now, but for member servers it
> is the same as for a Windows AD domain (yes, I think this should be more
> automatic).
>
> In terms of using nss_ldap on the DC, the only concern I have is that
> the [homes] share might not work if you do that.  Our DC code mostly
> avoids calling into nss, but that particular area does do it, and really
> does expect that nss_winbind is being used.
>
> For that reason, we generally suggest separation between the DC and
> other roles as the best way out of this situation.
>
> Andrew Bartlett
>
> --
> Andrew Bartletthttp://samba.org/~abartlet/
> Authentication Developer, Samba Team   http://samba.org
>
>
>
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] Samba 4, Winbind & RFC2307

[Thomas Simmons]

acl:search = false is commented out there, but the behavior is the same
either way.


On Sun, Dec 16, 2012 at 5:30 PM, Thomas Simmons  wrote:

> I am using 'template homedir' and 'template shell' for these attributes,
> which I'm fine with. It's the uidNumber and gidNumber that
> I'm primarily concerned with. My global section:
>
> [global]
> workgroup = TESTDOM
> realm = internal.testdom.com
> netbios name = ADC1
> server role = active directory domain controller
> dns forwarder = 10.10.65.1
> idmap_ldb:use rfc2307 = yes
> #acl:search = false
>
> template homedir = /home/%ACCOUNTNAME%
> template shell = /bin/sh
>
>
>
> On Sun, Dec 16, 2012 at 5:06 PM, Andrew Bartlett wrote:
>
>> On Sun, 2012-12-16 at 16:51 -0500, Thomas Simmons wrote:
>> > Hello Andrew,
>> >
>> >
>> > If functionality is not there, I certainly understand and can work
>> > around it. I just want to make sure I am not misunderstanding
>> > something.
>> >
>> >
>> > When you say I should set "idmap_ldb:use rfc2307=yes" in smb.conf on
>> > the DC, do you mean that by doing so I can use winbind (and the
>> > rfc2307 attributes) for *nix authentication on the DC? I am confused
>> > because I already have "idmap_ldb:use rfc2307 = yes" in my smb.conf
>> > (it gets added automatically with the classicupgrade and I always
>> > provision my "clean" test setup with "--use-rfc2307"). That actually
>> > works fine - the rfc2307 attributes are there and I can modify them in
>> > ADUC. If I configure the server to use NSS+LDAP for authentication, my
>> > users's uid number, gid number, shell, etc are what I have specified
>> > in ADUC. When I try using winbind, it is not using the rfc2307
>> > information from AD.
>>
>> That's odd, but remember that only the UID and GID values will be used
>> (not the shell or homedir, which is handled in a different bit of the
>> code).  However, your output below clearly shows that isn't
>> happening :-(
>>
>> > > Here I have NSS+LDAP configured and getent reports the
>> correct uidNumber
>> > > and gidNumber that I have specified in AD (rfc2307
>> attributes):
>> > >
>> > > root@ALW1:~# getent passwd | grep tuser
>> > > tuser1:*:10005:1:Test User1:/home/tuser1:/bin/sh
>> > > tuser2:*:10006:1:Test User2:/home/tuser2:/bin/sh
>> > > tuser3:*:10007:1:Test User3:/home/tuser3:/bin/sh
>> > >
>> > > Here (DC) I am using winbind for authentication, and getent
>> does not report
>> > > the correct uidNumber and gidNumber:
>> > >
>> > > [root@ADC1 ~]# getent passwd | grep tuser
>> > > TESTDOM\tuser1:*:325:100:Test User1:/home/tuser1:/bin/sh
>> > > TESTDOM\tuser2:*:326:100:Test User2:/home/tuser2:/bin/sh
>> > > TESTDOM\tuser3:*:327:100:Test User3:/home/tuser3:/bin/sh
>> >
>> As a test, can you set 'acl:search=false' and see if it makes a
>> difference?
>>
>> > Initially,  "idmap_ldb:use rfc2307 = yes" was the only idmap related
>> > entry in my smb.conf. When that did not work I tried a bunch of other
>> > "idmap config DOMAIN" settings.
>>
>> The code that handles that isn't hooked up yet.  I'm hoping someone will
>> take this on for 4.1.
>>
>> > Again, if this simply does not work at this time, I can use NSS and
>> > LDAP for logins on my DCs. With my S3 setup, I've always used LDAP for
>> > auth on *nix systems and am not terribly familiar with winbind, so I
>> > just want to make sure I'm not missing something. My next test will be
>> > setting up a member server. Can you tell me what entries I will need
>> > in my smb.conf to have winbind use the rfc2307 information from my S4
>> > DC on member servers?
>>
>> I don't recall the exact settings right now, but for member servers it
>> is the same as for a Windows AD domain (yes, I think this should be more
>> automatic).
>>
>> In terms of using nss_ldap on the DC, the only concern I have is that
>> the [homes] share might not work if you do that.  Our DC code mostly
>> avoids calling into nss, but that particular area does do it, and really
>> does expect that nss_winbind is being used.
>>
>> For that reason, we generally suggest separation between the DC and
>> other roles as the best way out of this situation.
>>
>> Andrew Bartlett
>>
>> --
>> Andrew Bartlett
>> http://samba.org/~abartlet/
>> Authentication Developer, Samba Team   http://samba.org
>>
>>
>>
>
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba

Re: [Samba] Samba 4, Winbind & RFC2307

[Thomas Simmons]

I am seeing similar behavior on an S4 member server. In this case, every
uid and gid is reported as "4294967295". As best I can tell, my smb.conf is
ok.

[root@ALW2 etc]# wbinfo -u
administrator
tuser1
tuser2
tuser3
krbtgt
guest

[root@ALW2 etc]# wbinfo -i tuser1
tuser1:*:4294967295:4294967295:Test User1:/home/tuser1:/bin/sh

[root@ALW2 etc]# getent passwd|grep tuser
tuser1:*:4294967295:4294967295:Test User1:/home/tuser1:/bin/sh
tuser2:*:4294967295:4294967295:Test User2:/home/tuser2:/bin/sh
tuser3:*:4294967295:4294967295:Test User3:/home/tuser3:/bin/sh


[global]
workgroup = TESTDOM
realm = internal.testdom.com
preferred master = no
server string = ALW2
security = ads
encrypt passwords = yes

idmap config TESTDOM:backend = ads
idmap config TESTDOM:schema_mode = rfc2307
idmap config TESTDOM:range = 1000-99

winbind enum users = yes
winbind enum groups = yes
winbind nested groups = yes
winbind use default domain = yes

template homedir = /home/%U
template shell = /bin/sh

If I add:

idmap backend = tdb
idmap uid = 100-199
idmap gid = 100-199

then I get uids and gids generated from this range. When I remove the
options, my users keep the generated uids and gids. I'm not sure how to
revert?


Thank you all for your help.


On Sun, Dec 16, 2012 at 5:32 PM, Thomas Simmons  wrote:

> acl:search = false is commented out there, but the behavior is the same
> either way.
>
>
> On Sun, Dec 16, 2012 at 5:30 PM, Thomas Simmons  wrote:
>
>> I am using 'template homedir' and 'template shell' for these attributes,
>> which I'm fine with. It's the uidNumber and gidNumber that
>> I'm primarily concerned with. My global section:
>>
>> [global]
>> workgroup = TESTDOM
>> realm = internal.testdom.com
>> netbios name = ADC1
>> server role = active directory domain controller
>> dns forwarder = 10.10.65.1
>> idmap_ldb:use rfc2307 = yes
>> #acl:search = false
>>
>> template homedir = /home/%ACCOUNTNAME%
>> template shell = /bin/sh
>>
>>
>>
>> On Sun, Dec 16, 2012 at 5:06 PM, Andrew Bartlett wrote:
>>
>>> On Sun, 2012-12-16 at 16:51 -0500, Thomas Simmons wrote:
>>> > Hello Andrew,
>>> >
>>> >
>>> > If functionality is not there, I certainly understand and can work
>>> > around it. I just want to make sure I am not misunderstanding
>>> > something.
>>> >
>>> >
>>> > When you say I should set "idmap_ldb:use rfc2307=yes" in smb.conf on
>>> > the DC, do you mean that by doing so I can use winbind (and the
>>> > rfc2307 attributes) for *nix authentication on the DC? I am confused
>>> > because I already have "idmap_ldb:use rfc2307 = yes" in my smb.conf
>>> > (it gets added automatically with the classicupgrade and I always
>>> > provision my "clean" test setup with "--use-rfc2307"). That actually
>>> > works fine - the rfc2307 attributes are there and I can modify them in
>>> > ADUC. If I configure the server to use NSS+LDAP for authentication, my
>>> > users's uid number, gid number, shell, etc are what I have specified
>>> > in ADUC. When I try using winbind, it is not using the rfc2307
>>> > information from AD.
>>>
>>> That's odd, but remember that only the UID and GID values will be used
>>> (not the shell or homedir, which is handled in a different bit of the
>>> code).  However, your output below clearly shows that isn't
>>> happening :-(
>>>
>>> > > Here I have NSS+LDAP configured and getent reports the
>>> correct uidNumber
>>> > > and gidNumber that I have specified in AD (rfc2307
>>> attributes):
>>> > >
>>> > > root@ALW1:~# getent passwd | grep tuser
>>> > > tuser1:*:10005:1:Test User1:/home/tuser1:/bin/sh
>>> > > tuser2:*:10006:1:Test User2:/home/tuser2:/bin/sh
>>> > > tuser3:*:10007:1:Test User3:/home/tuser3:/bin/sh
>>> > >
>>> > > Here (DC) I am using winbind for authentication, and getent
>>> does not report
>>> > > the correct uidNumber and gidNumber:
>>> > >
>>> > > [root@ADC1 ~]# getent passwd | grep tuser
>>> > > TESTDOM\tuser1:*:325:100:Test User1:/home/tuser1:/bin/sh
>>> > > TESTDOM\tuser2:*:326:100:Test User2:/home/tuser2:/bin/sh
>>> > > TESTDOM\tuser3:*:327:100:Test User3:/home/tuser3:/bin/sh
>>> >
>>> As a test, can you set 'acl:search=false' and see if it makes a
>>> difference?
>>>
>>> > Initially,  "idmap_ldb:use rfc2307 = yes" was the only idmap related
>>> > entry in my smb.conf. When that did not work I tried a bunch of other
>>> > "idmap config DOMAIN" settings.
>>>
>>> The code that handles that isn't hooked up yet.  I'm hoping someone will
>>> take this on for 4.1.
>>>
>>> > Again, if this simply does not work at this time, I can use NSS and
>>> > LDAP for logins on my DCs. With my S3 setup, I've always used LDAP for
>>> > auth o

[Samba] Samba3 joining W2k3 as member server

[Pieter De Wit]

Hi list,

I have tried with all my might to get a samba3 server (Ubuntu 12.04.1 LTS) to 
join a Windows 2003 domain as a member server, without any luck. I have 
used,from memory, the official way of doing this (aka, from the samba.org 
website). No matter what settings I use in smb.conf, the server always joins as 
a domain controller. This doesn't seem to break the domain how ever. All I am 
after is that my users do not need to enter a username/password for access from 
a domain PC to shares on my Linux box.

Any pointers please or is this intended as the server does single sign?

Thanks!

Pieter
Sent from my iPad
-- 
To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba