Here is my understanding of how I should proceed and what I have done so far: 1. Create a filesystem to hold the user home directories (DONE) 2. Export that filesystem as NFS from the Celerra for the Linux clients (DONE) 3. Configure the Celerra to query OpenLDAP to get Unix UIDs and GIDs for users coming in from the Linux side (DONE) 4. Create a Celerra CIFS server and join it to the AD domain (DONE) 5. Associate the homedir filesystem as a CIFS share with the Celerra CIFS server. (DONE) 6. Disable the default built-in Usermapper service on server_2 (DONE) 7. Change the resolver property so that Celerra does not append domain name to the user name when doing user lookups (DONE)
sounds good.
if you used the system with usermapper before make sure you dont have old entries from usermapper in the secmap
also make sure to read and understand the multi-protocol management guide to determine which access policy you want
Here's where the confusion begins.
8a. Configure Celerra to lookup UIDs/GIDs in OpenLDAP based on the Windows username (THOUGHT THAT IT SHOULD BE SET TO DO THAT BUT IT ISN'T - READ BELOW)
yes
Dont install SFU or IdmU unless you want to maintain the mapping in MS Active Directory instead of OpenLDAP
you probably want to set NTcred.winDomain
What I was expecting to see based on what I did in steps 1-7 and what I read in the User Mapping document is that when a Windows user tries to use the filesystem, the Celerra would say something like "SID 1-23456-234234-.... is associated with windows user CISWINNET\fran, lets query OpenLDAP for user fran" but I am not seeing that query to the OpenLDAP server.
that should happen once - i.e. the Celerra asking what UID the user fran has Once it got that info it will put it into the secmap and not ask again
Are you sure that both your nsswitch.conf file on the data mover and your ldap.conf are correct ?
Based on the Configuring EMC Celerra User Mapping document, page 13, where it discusses the steps the Celerra takes to try to map a SID to a UID, my understanding is this.... 1. Check the secmap for a cached mapping (I have deleted CISWINNET\fran from the secmap to make sure it is not cached)
yes, you can check this with server_cifssupport the -build option lets you build a credential similar to how a CIFS or NFS access would do
2. Ask the domain controller what username is associated with the SID (if I get this correctly, this means that the Celerra is asking what -Windows- username is associated with this SID, right? So is it fran, or is it the full CISWINNET\fran that would come back?)
yes
3. Use the username obtained in step 2 to ask the configured user mapping services for the UID associated with that Windows username. (The part that doesn't seem to be working at the moment)
well, it would first look into local data mover passwd file, NIS passwd file and ntxmap if there is a mapping for this Windows username to a Unix username if not it should lookup if a Unix username exists with literally the same name and get its UID/GID
So in my case, the only configured user mapping service is OpenLDAP, since I disabled the Usermapper.
well, if you do have disabled usermapper and can connect to the Celerra via CIFS then something is working If we were unable to get a mapping we wouldnt allow the CIFS connect
I would suggest to troubleshoot it step-by-step
first make sure LDAP is working then see that secmap gets populated then see if a file created from Windows gets the correct Unix owner then vice versa then see what you need in terms of permission mapping and access control see it you want/need ntcred
Due to the permanent nature of secmapping testing can be a bit tedious - make sure the delete the secmap entry after config changes
I'm having a little trouble finding where this is documented - what exactly does it do?
in the Parameter Guide, which has some other interesting params
nfs NTcred.winDomain Text string: any valid NetBIOS domain name
Specifies the Data Mover default Windows NetBIOS domain name to be used for NFS users accessing a file system where the ntcredential option has been used. This value is used only if several different SIDs match the user¿s UNIX UID, or the UID-to-name reverse mapping returns an ambiguous username (no domain). This parameter does not apply to NFSv4, but can be used with NFSv2 and NFSv3.
It's basically used for the ntcredential option, which enhances the group access mapping for NFS access
Now that I fixed nsswitch.conf the behavior is interesting. It is now finding my Unix UID 514 correctly when I create files from Windows, but it is assigning me GID 32770 instead of the expected 510. My OpenLDAP record has both uidNumber and gidNumber in it. Any thoughts there?
32770 is most probably from user mapper - either you haven't turned it off or the mapping is still in the secmap
secmap is always looked at first
with server_cifssupport you can also display which naming source a mapping is coming from
[nasadmin@celerramgmt site]$ more ldap.conf.server_2 nss_base_passwd ou=People,dc=cis,dc=uab,dc=edu nss_base_shadow ou=People,dc=cis,dc=uab,dc=edu nss_base_group ou=Group,dc=cis,dc=uab,dc=edu
if not it should lookup if a Unix username exists with literally the same name and get its UID/GID
Now that I fixed nsswitch.conf the behavior is interesting. It is now finding my Unix UID 514 correctly when I create files from Windows, but it is assigning me GID 32770 instead of the expected 510. My OpenLDAP record has both uidNumber and gidNumber in it. Any thoughts there?
Thanks for the help thus far, I feel like I am close to a working config now.
Now that I fixed nsswitch.conf the behavior is interesting. It is now finding my Unix UID 514 correctly when I create files from Windows, but it is assigning me GID 32770 instead of the expected 510.
Just like you cautioned me, leftover from when usermapper was running. :-/ Sorry I was impatient and didn't catch that right away.
Deleted that record with "server_cifssupport server_2 -secmap -delete -name Domain\ Users -domain CISWINNET", disconnected and reconnected to the share, and now new files created on Windows show up as fran:staff on Linux.
I'm sure you'll be back once you get into access policies
This actually seems pretty straightforward (which of course means it won't be at all .
But it seems like we are a good candidate for MIXED mode, because we would like changes on one side to be synchronized to the other, and that seems to be the best choice for doing so. Of course it still leads to scenarios where it looks on the UNIX side like there are more permissive access rights than really exist, but that's a better scenario than thinking you've locked down a file when all you've really done is lock it down for one side/protocol.
Early testing with MIXED mode this afternoon seems to behave about as close to the current Samba environment as any of the Celerra access mode options would, which is good since we're hoping to not hopelessly confuse our end users with this transition.
P.S.: are you by any chance going to EMC World and want to meet another university customer ?
I would love to and there was some talk of me going, but the budget situation is probably going to prevent me from doing so, unfortunately.
well, best way should be MIXED and NFSv4 - unfortunately NFSv4 adoption seems to be very slow
Unfortunately some things just dont translate very well between Unix and Windows: - Windows admins like to use nested groups (which arent possible in Unix) and base their ACLs on them - Windows doesnt have the notion of a primary group for a user - mapping lots of ACLs and lots of permission types to just the three ugo and rwx in Unix has to be incomplete - Unix still has that concept that root is excempt from access controls
Also in university environments there's the matter that NFS isnt very secure if you cant control the clients (IP or UID/GID spoofing)
Rainer_EMC
4 Operator
•
8.6K Posts
0
April 29th, 2009 08:00
what I have done so far:
1. Create a filesystem to hold the user home
directories (DONE)
2. Export that filesystem as NFS from the Celerra
for the Linux clients (DONE)
3. Configure the Celerra to query OpenLDAP to get
Unix UIDs and GIDs for users coming in from the
Linux side (DONE)
4. Create a Celerra CIFS server and join it to the
AD domain (DONE)
5. Associate the homedir filesystem as a CIFS share
with the Celerra CIFS server. (DONE)
6. Disable the default built-in Usermapper service
on server_2 (DONE)
7. Change the resolver property so that Celerra does
not append domain name to the user name when doing
user lookups (DONE)
sounds good.
if you used the system with usermapper before make sure you dont have old entries from usermapper in the secmap
also make sure to read and understand the multi-protocol management guide to determine which access policy you want
8a. Configure Celerra to lookup UIDs/GIDs in OpenLDAP based on the Windows username (THOUGHT THAT IT SHOULD BE SET TO DO THAT BUT IT ISN'T - READ BELOW)
yes
Dont install SFU or IdmU unless you want to maintain the mapping in MS Active Directory instead of OpenLDAP
you probably want to set NTcred.winDomain
document is that when a Windows user tries to use the filesystem, the Celerra would say something like "SID
1-23456-234234-.... is associated with windows user CISWINNET\fran, lets query OpenLDAP for user fran"
but I am not seeing that query to the OpenLDAP server.
that should happen once - i.e. the Celerra asking what UID the user fran has
Once it got that info it will put it into the secmap and not ask again
Are you sure that both your nsswitch.conf file on the data mover and your ldap.conf are correct ?
Celerra takes to try to map a SID to a UID, my understanding is this....
1. Check the secmap for a cached mapping (I have deleted CISWINNET\fran from the secmap to make sure it is not cached)
yes, you can check this with server_cifssupport
the -build option lets you build a credential similar to how a CIFS or NFS access would do
this means that the Celerra is asking what -Windows- username is associated with this SID, right? So is
it fran, or is it the full CISWINNET\fran that would come back?)
yes
associated with that Windows username. (The part that doesn't seem to be working at the moment)
well, it would first look into local data mover passwd file, NIS passwd file and ntxmap if there is a mapping for this Windows username to a Unix username
if not it should lookup if a Unix username exists with literally the same name and get its UID/GID
well, if you do have disabled usermapper and can connect to the Celerra via CIFS then something is working
If we were unable to get a mapping we wouldnt allow the CIFS connect
I would suggest to troubleshoot it step-by-step
first make sure LDAP is working
then see that secmap gets populated
then see if a file created from Windows gets the correct Unix owner
then vice versa
then see what you need in terms of permission mapping and access control
see it you want/need ntcred
Due to the permanent nature of secmapping testing can be a bit tedious - make sure the delete the secmap entry after config changes
Rainer_EMC
4 Operator
•
8.6K Posts
0
April 29th, 2009 10:00
I'm having a little trouble finding where this is documented - what exactly does it do?
in the Parameter Guide, which has some other interesting params
nfs NTcred.winDomain Text string: any valid NetBIOS domain name
Specifies the Data Mover default Windows NetBIOS domain
name to be used for NFS users accessing a file system where
the ntcredential option has been used. This value is used only if
several different SIDs match the user¿s UNIX UID, or the
UID-to-name reverse mapping returns an ambiguous username
(no domain).
This parameter does not apply to NFSv4, but can be used with
NFSv2 and NFSv3.
It's basically used for the ntcredential option, which enhances the group access mapping for NFS access
correctly when I create files from Windows, but it is assigning me GID 32770 instead of the expected 510.
My OpenLDAP record has both uidNumber and gidNumber
in it. Any thoughts there?
32770 is most probably from user mapper - either you haven't turned it off or the mapping is still in the secmap
secmap is always looked at first
with server_cifssupport you can also display which naming source a mapping is coming from
flyerguybham
8 Posts
0
April 29th, 2009 10:00
I'm having a little trouble finding where this is documented - what exactly does it do?
data mover and your ldap.conf are correct ?
You got me - I hadn't adjusted the nsswitch.conf yet. Now here is what I have in both of these files:
# /.etc/nsswitch.conf :
#
passwd: files ldap
group: files ldap
hosts: dns ldap files
netgroup: files ldap
[nasadmin@celerramgmt site]$ more ldap.conf.server_2
nss_base_passwd ou=People,dc=cis,dc=uab,dc=edu
nss_base_shadow ou=People,dc=cis,dc=uab,dc=edu
nss_base_group ou=Group,dc=cis,dc=uab,dc=edu
with literally the same name and get its UID/GID
Now that I fixed nsswitch.conf the behavior is interesting. It is now finding my Unix UID 514 correctly when I create files from Windows, but it is assigning me GID 32770 instead of the expected 510. My OpenLDAP record has both uidNumber and gidNumber in it. Any thoughts there?
Thanks for the help thus far, I feel like I am close to a working config now.
flyerguybham
8 Posts
0
April 29th, 2009 10:00
interesting. It is now finding my Unix UID 514
correctly when I create files from Windows, but it is
assigning me GID 32770 instead of the expected 510.
SECMAP GROUP MAPPING TABLE
GID Origin Date of creation Name SID
32769 usermapper Tue Apr 28 16:33:03 2009 CISWINNET\Domain Admins S-1-5-15-8f557f31-8a7d1d03-2420310a-200
32770 usermapper Tue Apr 28 16:33:12 2009 CISWINNET\Domain Users S-1-5-15-8f557f31-8a7d1d03-2420310a-201
[SNIP]
510 ldap Wed Apr 29 12:17:09 2009 CISWINNET\staff S-1-5-15-8f557f31-8a7d1d03-2420310a-469
Just like you cautioned me, leftover from when usermapper was running. :-/ Sorry I was impatient and didn't catch that right away.
Deleted that record with "server_cifssupport server_2 -secmap -delete -name Domain\ Users -domain CISWINNET", disconnected and reconnected to the share, and now new files created on Windows show up as fran:staff on Linux.
Thanks!
Rainer_EMC
4 Operator
•
8.6K Posts
0
April 29th, 2009 11:00
I'm sure you'll be back once you get into access policies
some params to check out:
acl.extacl Bit 1
acl.extendExtraGid
acl.useUnixGid
acl.takegroupship
acl.unixCheckAcl
filesystem.rstchown
acl.restrictedTakeOwnership
admin.adminAreRoot
acl.sortAces
regards
Rainer
P.S.: are you by any chance going to EMC World and want to meet another university customer ?
flyerguybham
8 Posts
0
April 29th, 2009 13:00
policies
This actually seems pretty straightforward (which of course means it won't be at all
But it seems like we are a good candidate for MIXED mode, because we would like changes on one side to be synchronized to the other, and that seems to be the best choice for doing so. Of course it still leads to scenarios where it looks on the UNIX side like there are more permissive access rights than really exist, but that's a better scenario than thinking you've locked down a file when all you've really done is lock it down for one side/protocol.
Early testing with MIXED mode this afternoon seems to behave about as close to the current Samba environment as any of the Celerra access mode options would, which is good since we're hoping to not hopelessly confuse our end users with this transition.
want to meet another university customer ?
I would love to and there was some talk of me going, but the budget situation is probably going to prevent me from doing so, unfortunately.
Rainer_EMC
4 Operator
•
8.6K Posts
0
April 30th, 2009 02:00
Unfortunately some things just dont translate very well between Unix and Windows:
- Windows admins like to use nested groups (which arent possible in Unix) and base their ACLs on them
- Windows doesnt have the notion of a primary group for a user
- mapping lots of ACLs and lots of permission types to just the three ugo and rwx in Unix has to be incomplete
- Unix still has that concept that root is excempt from access controls
Also in university environments there's the matter that NFS isnt very secure if you cant control the clients (IP or UID/GID spoofing)