samba - Dec 2012 - Samba4 LDAP ACLs - access to POSIX attributes from a non-admin account

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. I do not 
know enough about AD configuration to figure out where the ACLs are 
stored for this, and documentation has been scarce to say the least. 
Thus I have come to this mailing list for guidance.

An alternative strategy would be to enable anonymous binding on the LDAP 
server, but the (slightly less scarce) documentation shows that to do 
that requires each entry be specifically set to allow this, which seems 
to be more hassle than it is worth. Any help on this would also be 
greatly appreciated.

Thanks,
Rob

On the samba-technical mailing list there is this exact problem 
detailed, so your help is no longer needed to configure reading of 
unixHomeDirectory and loginShell by other users, but the question about 
anonymous access still stands - it would be much better for each client 
to have anonymous access to LDAP rather than needing the dedicated user, 
which brings with it security holes.

On 14/12/12 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.

On 15/12/12 13:31, Achim Gottinger wrote:
> It might work if you give Anonymous full read Access to the cn=Users 
> branch via AD User and Group management.
How is it possible to do this from the Samba4 server? Unfortunately 
Windows is out of the question here, because this will be part of 
Karoshi Server which will be distributed as a self-contained Linux 
distribution. Therefore the ideal solution would be either direct LDAP 
modification, or use of samba-tool or other utilities.

Hello Rob,

You can enable anonymous binding to AD by creating the attribute
"dsHeuristics" with a value of "0000002001001" 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

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 "0000002001001" 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 
>
<http://technet.microsoft.com/en-us/library/cc816788%28v=ws.10%29.aspx>
>
>

On Fri, 2012-12-14 at 18:03 +0000, 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 Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org