Michael Anderson wrote:
Quoting Jordan Brown :
If you have
- a UNIX user UU, whose primary group is UG1
- a Windows user WU, whose primary group is WG
- WU is mapped to UU
- WG is mapped to UG2
Before build 137, if WU creates a file, we consider the user and group
separately, mapping WU to UU a
Quoting Jordan Brown :
Michael Anderson wrote:
Aha! After 'c)' above, things are looking better:
Excellent.
Interesting:
when I copy a file from the CIFS share to the windows desktop, the
user's unix GID disappears from the permissions, and the 'SYSTEM'
group appears instead.
I beli
Jordan Brown wrote:
6923083 ZFS/NFS/SMB ACL interoperability changes
In ZFS, all access control is through access control lists. There are
no traditional UNIX permissions stored; UNIX permissions are
synthesized when needed by processing the access control lists.
Before build 139, that algo
Michael Anderson wrote:
Aha! After 'c)' above, things are looking better:
Excellent.
Interesting:
when I copy a file from the CIFS share to the windows desktop, the
user's unix GID disappears from the permissions, and the 'SYSTEM'
group appears instead.
I believe that most Windows copy pr
Quoting Jordan Brown :
Michael Anderson wrote:
Here's a query that may help to illuminate matters. You have to run it
as root so that it can use your system's credentials. This is roughly
the query that the mapping code uses; if it doesn't retrieve the
appropriate attributes then mapping isn'
Michael Anderson wrote:
Here's a query that may help to illuminate matters. You have to run it
as root so that it can use your system's credentials. This is roughly
the query that the mapping code uses; if it doesn't retrieve the
appropriate attributes then mapping isn't going to work.
|# ldap
Quoting Jordan Brown :
Michael Anderson wrote:
So, this means that the entries are being found in the directory,
but for some reason aren't being or can't be used for mapping - is
that correct?
get-namemap and set-namemap operate on the "real" data stored on the
Domain Controllers, while
Michael Anderson wrote:
So, this means that the entries are being found in the directory, but
for some reason aren't being or can't be used for mapping - is that
correct?
get-namemap and set-namemap operate on the "real" data stored on the
Domain Controllers, while normal mapping operations o
Quoting Jordan Brown :
Michael Anderson wrote:
What's interesting, is that:
svccfg -s svc:/system/idmap setprop
config/ds_name_mapping_enabled=boolean: true
svccfg -s svc:/system/idmap setprop
config/ad_unixuser_attr=astring:msSFU30Name
svccfg -s svc:/system/idmap setprop
config/ad_un
Michael Anderson wrote:
What's interesting, is that:
svccfg -s svc:/system/idmap setprop
config/ds_name_mapping_enabled=boolean: true
svccfg -s svc:/system/idmap setprop
config/ad_unixuser_attr=astring:msSFU30Name
svccfg -s svc:/system/idmap setprop config/ad_unixuser_attr=astring:
msSFU30Gid
I am getting the same error. Configuring idmap to use AD does not seem be in
used by idmap.
The ephermal ID you are getting in idmap show is probably a residue from before
the AD is configured. Once you remove the /var/idmap/idmap.db and restart it,
you would not receive these any more.
When
Quoting Jordan Brown :
Michael Anderson wrote:
We're migrating from a BSD Samba/NFS server to OpenSolaris CIFS/NFS,
using a W2k3 AD Server with MS SFU for auth and user database.
What build are you running?
# uname -a
SunOS opensolaris-svn 5.11 snv_111b i86pc i386 i86pc
and
SunOS nexenta2
Michael Anderson wrote:
We're migrating from a BSD Samba/NFS server to OpenSolaris CIFS/NFS,
using a W2k3 AD Server with MS SFU for auth and user database.
What build are you running?
Setting up LDAP with the SFU attributes works fine for NFS, but I cannot
figure out the CIFS side of things.
13 matches
Mail list logo