Re: [cifs-discuss] idmap and SFU
Quoting Jordan Brown jordan.br...@oracle.com: 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 programs do not attempt to preserve the ACL. If create a file on Windows, there exist windows permissions for the user and SYSTEM, the unix group is 'nobody', and the unix owner is no longer owner, but a generic user with certain ACL rights to the file and can read, write, but not delete files. So the perms look like this on opensolaris: # ls -vl created_on_windows.txt --+ 1 vuser1 2147524611 0 Mai 26 00:03 created_on_windows.txt 0:user:vuser1:read_data/write_data/append_data/read_xattr/write_xattr /execute/delete_child/read_attributes/write_attributes/delete /read_acl/write_acl/write_owner/synchronize:allow 1:group:2147483648:read_data/write_data/append_data/read_xattr /write_xattr/execute/delete_child/read_attributes/write_attributes /delete/read_acl/write_acl/write_owner/synchronize:allow You might want to add ad to your /etc/nsswitch.conf passwd and group lines, so that ls -l can show you the Windows users and groups instead of the big numbers like 2147524611. See ad(5). Ah, yes, right. You might try $ idmap show -cv gid:2147524611 winname to confirm what the group setting is on that file. (Probably the answer is Domain Users.) Right again. I suppose I have to walk the share with inheritable 'owner@' permissions, or something like that? That might help ls -l produce good-looking permission values. It also depends on what semantics you want: do you want the access control to apply to the current owner of the file (which is usual UNIX behavior) or do you want it to apply to some specific user (which is usual Windows behavior)? There are two recent CRs that are relevant to this behavior: 6899409 Preserve owner@/group@ across SMB UNIX has a concept of an access control entry (the rwx-- bits in traditional UNIX) that applies to the current owner of a file, whoever that might be. Windows doesn't have this concept. Before build 132, for Windows purposes we would translate the owner permissions into an access control entry that specified the current owner of the file. That looked pretty much right, but caused a problem: if the Windows system wrote that access control list back to the server, the effect would be to change that access control entry from the current owner to some specific user, changing its semantics. (Automatically converting it back to a current owner entry would cause a similar problem.) Starting in build 132, we report a special Current owner user to Windows, so that the semantics are preserved when the Windows system makes changes. (Similar comments apply to current group.) 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 algorithm considered only current owner and current group entries when synthesizing traditional UNIX permissions. That often resulted in permissions that looked like - even when the owner of the file had full access, because that access was granted explicitly to that user rather than to the current owner. Starting in build 139, access control entries that refer specifically to the user who happens to own the file are also considered. Note: Since the actual access control checks use the access control list, these bad permissions reports largely did not affect access; they just worried humans looking at them. (Again, similar comments apply to current group.) Note that these two can combine to turn a current owner access control entry into a specific-user entry, and thus yield a - permission list. But how do I make newly created files belong to the unix primary group? To which UNIX primary group do you refer? They probably belong to the Windows primary group of the Windows user. Perhaps you want them to belong to the UNIX primary group of the UNIX user? Indeed. That is: 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 and WG to UG2. The file thus ends up with owner=UU and group=UG2. That's not unreasonable, but it's probably not what a UNIX-centric user expects, because it's not what you would have gotten if UU created the file. CR 6906874 Automatic primary group mapping based on user mapping, delivered in build 137, changes this behavior. With the new behavior, for the
Re: [cifs-discuss] idmap and SFU
Michael Anderson wrote: Quoting Jordan Brown jordan.br...@oracle.com: 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 and WG to UG2. The file thus ends up with owner=UU and group=UG2. [...] [our users] are used to newly created files belonging to the primary unix group of the unix user, regardless of whether they created on windows or unix. They also expect to see the permissions of the mapped unix user when they do a ls -l in Unix. That is when vus...@elego.de creates a file on windows, he expects to see something like: -rwxr- 1 vuser1 Gvuser1 on his NFS mount. If I understand correctly, these behaviors have been incorporated into the newest builds. Yes. In the meantime, it *may* be practical for you to work around this issue by tightly synchronizing your UNIX and Windows groups and group memberships. Refer back to my explanation above for the algorithm your version of the software is using. You have a Windows user vus...@elego.de (WU) mapped to a UNIX user vuser1 (UU). Windows user vus...@elego.de has Domain us...@elego.de (WG) set as the primary group. UNIX user vuser1 has Gvuser1 ( UG1) set as the primary group. Domain us...@elego.de does not have a mapping to a UNIX group. Net, you end up with the group setting for newly created files being Domain us...@elego.de. You could: - Create a Windows group gvus...@elego.de (WG). - Select gvus...@elego.de as the primary group for vus...@elego.de (WU). - Map the Windows group gvus...@elego.de to the UNIX group Gvuser1 (UG1/UG2). If you did this, the software that you are running would pick up vus...@elego.de's Windows primary group, gvus...@elego.de, map it to the equivalent UNIX group, Gvuser1, and use that as the default group setting for newly created files. Both paths to determining the UNIX group to use would lead to Gvuser1, and the net effect would be what you are expecting. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] idmap and SFU
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 programs do not attempt to preserve the ACL. If create a file on Windows, there exist windows permissions for the user and SYSTEM, the unix group is 'nobody', and the unix owner is no longer owner, but a generic user with certain ACL rights to the file and can read, write, but not delete files. So the perms look like this on opensolaris: # ls -vl created_on_windows.txt --+ 1 vuser1 2147524611 0 Mai 26 00:03 created_on_windows.txt 0:user:vuser1:read_data/write_data/append_data/read_xattr/write_xattr /execute/delete_child/read_attributes/write_attributes/delete /read_acl/write_acl/write_owner/synchronize:allow 1:group:2147483648:read_data/write_data/append_data/read_xattr /write_xattr/execute/delete_child/read_attributes/write_attributes /delete/read_acl/write_acl/write_owner/synchronize:allow You might want to add ad to your /etc/nsswitch.conf passwd and group lines, so that ls -l can show you the Windows users and groups instead of the big numbers like 2147524611. See ad(5). You might try $ idmap show -cv gid:2147524611 winname to confirm what the group setting is on that file. (Probably the answer is Domain Users.) I suppose I have to walk the share with inheritable 'owner@' permissions, or something like that? That might help ls -l produce good-looking permission values. It also depends on what semantics you want: do you want the access control to apply to the current owner of the file (which is usual UNIX behavior) or do you want it to apply to some specific user (which is usual Windows behavior)? There are two recent CRs that are relevant to this behavior: 6899409 Preserve owner@/group@ across SMB UNIX has a concept of an access control entry (the rwx-- bits in traditional UNIX) that applies to the current owner of a file, whoever that might be. Windows doesn't have this concept. Before build 132, for Windows purposes we would translate the owner permissions into an access control entry that specified the current owner of the file. That looked pretty much right, but caused a problem: if the Windows system wrote that access control list back to the server, the effect would be to change that access control entry from the current owner to some specific user, changing its semantics. (Automatically converting it back to a current owner entry would cause a similar problem.) Starting in build 132, we report a special Current owner user to Windows, so that the semantics are preserved when the Windows system makes changes. (Similar comments apply to current group.) 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 algorithm considered only current owner and current group entries when synthesizing traditional UNIX permissions. That often resulted in permissions that looked like - even when the owner of the file had full access, because that access was granted explicitly to that user rather than to the current owner. Starting in build 139, access control entries that refer specifically to the user who happens to own the file are also considered. Note: Since the actual access control checks use the access control list, these bad permissions reports largely did not affect access; they just worried humans looking at them. (Again, similar comments apply to current group.) Note that these two can combine to turn a current owner access control entry into a specific-user entry, and thus yield a - permission list. But how do I make newly created files belong to the unix primary group? To which UNIX primary group do you refer? They probably belong to the Windows primary group of the Windows user. Perhaps you want them to belong to the UNIX primary group of the UNIX user? That is: 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 and WG to UG2. The file thus ends up with owner=UU and group=UG2. That's not unreasonable, but it's probably not what a UNIX-centric user expects, because it's not what you would have gotten if UU created the file. CR 6906874 Automatic primary group mapping based on user mapping, delivered in build 137, changes this behavior. With the new behavior, for the purposes of the group setting of newly created files
Re: [cifs-discuss] idmap and SFU
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 algorithm considered only current owner and current group entries when synthesizing traditional UNIX permissions. That often resulted in permissions that looked like - even when the owner of the file had full access, because that access was granted explicitly to that user rather than to the current owner. Starting in build 139, access control entries that refer specifically to the user who happens to own the file are also considered. Note: Since the actual access control checks use the access control list, these bad permissions reports largely did not affect access; they just worried humans looking at them. (Again, similar comments apply to current group.) I should note that that CR addressed a number of improvements in the treatment of ACLs; this is only one of the things that it changed. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] idmap and SFU
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. |# ldapsearch -R -h yourGCserver -p 3268 -s subtree -b '' -o mech=gssapi -o authzid='' '(sAMAccountName=vuser1)'| # exte.comd LDIF # # LDAPv3 # base with scope subtree # filter: (sAMAccountName=vuser1) # requesting: ALL # # vuser1, Users, domain.com dn: CN=vuser1,CN=Users,DC=domain,DC.com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: vuser1 givenName: vuser1 distinguishedName: CN=vuser1,CN=Users,DC=domain,DC.com instanceType: 4 whenCreated: 20091215103053.0Z whenChanged: 20100510065727.0Z displayName: vuser1 uSNCreated: 1122529 uSNChanged: 1352342 name: vuser1 objectGUID:: LtWX7JjtpUO3s3EVCIg1sg== userAccountControl: 512 primaryGroupID: 513 objectSid:: AQUAAAUVlY9rWhrl0jyBPJSISQUAAA== sAMAccountName: vuser1 sAMAccountType: 805306368 userPrincipalName: vus...@domain.com objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=domain,DC.com msSFU30Name: vuser1 msSFU30UidNumber: 100029 So that's what that looks like. Should be enough, at least for uid resolution, or? Is that the output from the ldapsearch command that I gave, or from some other tool? It is important, for instance, that the ldapsearch is connecting to port 3268 (the GC port) rather than to 389 (the DC/LDAP port). Yes, it was a transcription error. But my experiments have stopped working. This was after I deleted /var/idmap/db and restarted idmapd. I also replicated msSFU30Name to the GC. Now I get: # idmap get-namemap winuser:mand Querying DNS for SRV RRs named '_ldap._tcp.dc._msdcs' for 'domain.com' Found _ldap._tcp.dc._msdcs.domain.com 600 IN SRV [0][100] bdc2.domain.com:389 No namemap found in AD. Here you are looking at user mand, where you were previously looking at vuser1. I assume that's both have msSFU30Name populated? I assume also that you have anonymized some of this output, replacing your actual domain with domain.com? [later...] OK, I've done a bunch of experimentation and I may have some answers. I can't immediately explain why get-namemap used to work for you and now doesn't. I have found two bugs in directory-based name mapping that might, either alone or together, explain your problems. 6954913 Mapping to ephemeral followed by directory-based name mapping does not use directory data 6954902 mapping to unknown type does not use directory-based mapping information 6954913 makes it so that changes to the directory-based name mapping configuration and the directory data that it uses may not be picked up by the mapping process. Largely, once the configuration and directory data have been changed and the system rebooted, this shouldn't be a problem, however... 6954902 makes it so that an attempt to map a Windows identity to an unknown UNIX type will erroneously ignore directory-based mapping data, which can also trigger 6954913. This should be fairly rare, since mapping to an unknown UNIX type is used only rarely. The only two cases that I know of are certain SMB ACL operations and idmap show with no target type. I'm working on both of those, but it will be a while before any change is available externally. In the meantime, you can work around most of the problems by: 1) After you make changes to the directory-based name mapping configuration, and after you make changes to the mapping data in the directory, clear the idmap cache. There are about four ways to do this: a) idmap flush -a is the best answer, if you have a recent enough system that it's available. b) Reboot the system c) svcadm disable idmap, then rm /var/run/idmap/idmap.db, then svcadm enable idmap d) /lib/svc/bin/sqlite /var/run/idmap/idmap.db sqlite delete from idmap_cache; sqlite delete from name_cache; sqlite ^D Please note that (a) is the long-term answer; the others rely on implementation details that are subject to change. 2) When you experiment with idmap show, always specify a target type. That is, instead of saying idmap show -c u...@example.com, say idmap show -c u...@example.com uid or idmap show -c u...@example.com unixuser. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] idmap and SFU
Quoting Jordan Brown jordan.br...@oracle.com: 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. |# ldapsearch -R -h yourGCserver -p 3268 -s subtree -b '' -o mech=gssapi -o authzid='' '(sAMAccountName=vuser1)'| # exte.comd LDIF # # LDAPv3 # base with scope subtree # filter: (sAMAccountName=vuser1) # requesting: ALL # # vuser1, Users, domain.com dn: CN=vuser1,CN=Users,DC=domain,DC.com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: vuser1 givenName: vuser1 distinguishedName: CN=vuser1,CN=Users,DC=domain,DC.com instanceType: 4 whenCreated: 20091215103053.0Z whenChanged: 20100510065727.0Z displayName: vuser1 uSNCreated: 1122529 uSNChanged: 1352342 name: vuser1 objectGUID:: LtWX7JjtpUO3s3EVCIg1sg== userAccountControl: 512 primaryGroupID: 513 objectSid:: AQUAAAUVlY9rWhrl0jyBPJSISQUAAA== sAMAccountName: vuser1 sAMAccountType: 805306368 userPrincipalName: vus...@domain.com objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=domain,DC.com msSFU30Name: vuser1 msSFU30UidNumber: 100029 So that's what that looks like. Should be enough, at least for uid resolution, or? Is that the output from the ldapsearch command that I gave, or from some other tool? It is important, for instance, that the ldapsearch is connecting to port 3268 (the GC port) rather than to 389 (the DC/LDAP port). Yes, it is. A query on port 389 returns several other msSFU30 attributes in addition to those replicated in the GC. Yes, it was a transcription error. But my experiments have stopped working. This was after I deleted /var/idmap/db and restarted idmapd. I also replicated msSFU30Name to the GC. Now I get: # idmap get-namemap winuser:mand Querying DNS for SRV RRs named '_ldap._tcp.dc._msdcs' for 'domain.com' Found _ldap._tcp.dc._msdcs.domain.com 600 IN SRV [0][100] bdc2.domain.com:389 No namemap found in AD. Here you are looking at user mand, where you were previously looking at vuser1. I assume that's both have msSFU30Name populated? Yes. I assume also that you have anonymized some of this output, replacing your actual domain with domain.com? Yes. [later...] OK, I've done a bunch of experimentation and I may have some answers. I can't immediately explain why get-namemap used to work for you and now doesn't. After setting up from scratch again, get-namemap works again. I would attribute this analomy to some fat-fingered typing error of mine along the way somewhere. I have found two bugs in directory-based name mapping that might, either alone or together, explain your problems. 6954913 Mapping to ephemeral followed by directory-based name mapping does not use directory data 6954902 mapping to unknown type does not use directory-based mapping information 6954913 makes it so that changes to the directory-based name mapping configuration and the directory data that it uses may not be picked up by the mapping process. Largely, once the configuration and directory data have been changed and the system rebooted, this shouldn't be a problem, however... 6954902 makes it so that an attempt to map a Windows identity to an unknown UNIX type will erroneously ignore directory-based mapping data, which can also trigger 6954913. This should be fairly rare, since mapping to an unknown UNIX type is used only rarely. The only two cases that I know of are certain SMB ACL operations and idmap show with no target type. I'm working on both of those, but it will be a while before any change is available externally. In the meantime, you can work around most of the problems by: 1) After you make changes to the directory-based name mapping configuration, and after you make changes to the mapping data in the directory, clear the idmap cache. There are about four ways to do this: a) idmap flush -a is the best answer, if you have a recent enough system that it's available. b) Reboot the system c) svcadm disable idmap, then rm /var/run/idmap/idmap.db, then svcadm enable idmap d) /lib/svc/bin/sqlite /var/run/idmap/idmap.db sqlite delete from idmap_cache; sqlite delete from name_cache; sqlite ^D Please note that (a) is the long-term answer; the others rely on implementation details that are subject to change. 2) When you experiment with idmap show, always specify a target type. That is, instead of saying idmap show -c u...@example.com, say idmap show -c u...@example.com uid or idmap show -c u...@example.com unixuser. Aha! After 'c)' above, things are looking better: # idmap show -cv vus...@domain.com uid winuser:vus...@domain.com - uid:100029 Source: New Method: AD Directory DN: CN=vuser1,CN=Users,DC=domain,DC=com Attribute:
Re: [cifs-discuss] idmap and SFU
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 operate get their information from a subset stored on the Global Catalog servers. My guess is that the attributes were not being propagated to the GC. I believe that the problem is that msSFU30Name isn't exported to the Global Catalog, and the directory-based name mapping stuff requires that the data be visible in the Global Catalog. Here's an article that says how to make an attribute visible in the Global Catalog: http://support.microsoft.com/default.aspx?scid=kb;EN-US;248717 Hmm, I tried that, but it didn't seem to help. It might take a while for the GC to get updated. I don't know how that mechanism works, but I believe they are separate databases and so I doubt that changing the setting for an attribute has immediate effect. I'm wondering if I should extend the AD schema as described in the CIFS docs. Although it would seem redundant, since the desired data is already in the SFU extensions. I would hope that you could use the existing fields. Note that you might be able to use sAMAccountName, which is already propagated to the GC. sAMAccountName is shown in the UI as Pre-Windows 2000 logon name, and I believe is always a copy of the msSFU30Name. Thanks for all the assistance. Very helpful. Sorry I can't be more definitive. 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. |# ldapsearch -R -h yourGCserver -p 3268 -s subtree -b '' -o mech=gssapi -o authzid='' '(sAMAccountName=vuser1)' | BTW, I just noticed something in a previous message: 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: msSFU30GidNumber First, I assume that the last command should be setting ad_unixgroup_attr, not ad_unixuser_attr. I assume that's simply a transcription error, since your experiments seem to work. Second, setting ad_unixgroup_attr to msSFU30GidNumber will *not* work. This mechanism needs an attribute that contains a group *name*, not a group *number*. Of course it would be easy to allow it to accept either, but it doesn't currently. That doesn't explain your problems with mapping vuser1, though. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] idmap and SFU
Quoting Jordan Brown jordan.br...@oracle.com: 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 operate get their information from a subset stored on the Global Catalog servers. My guess is that the attributes were not being propagated to the GC. I believe that the problem is that msSFU30Name isn't exported to the Global Catalog, and the directory-based name mapping stuff requires that the data be visible in the Global Catalog. Here's an article that says how to make an attribute visible in the Global Catalog: http://support.microsoft.com/default.aspx?scid=kb;EN-US;248717 Hmm, I tried that, but it didn't seem to help. It might take a while for the GC to get updated. I don't know how that mechanism works, but I believe they are separate databases and so I doubt that changing the setting for an attribute has immediate effect. I'm wondering if I should extend the AD schema as described in the CIFS docs. Although it would seem redundant, since the desired data is already in the SFU extensions. I would hope that you could use the existing fields. Note that you might be able to use sAMAccountName, which is already propagated to the GC. sAMAccountName is shown in the UI as Pre-Windows 2000 logon name, and I believe is always a copy of the msSFU30Name. Thanks for all the assistance. Very helpful. Sorry I can't be more definitive. 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. |# ldapsearch -R -h yourGCserver -p 3268 -s subtree -b '' -o mech=gssapi -o authzid='' '(sAMAccountName=vuser1)' | # exte.comd LDIF # # LDAPv3 # base with scope subtree # filter: (sAMAccountName=vuser1) # requesting: ALL # # vuser1, Users, domain.com dn: CN=vuser1,CN=Users,DC=domain,DC.com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: user cn: vuser1 givenName: vuser1 distinguishedName: CN=vuser1,CN=Users,DC=domain,DC.com instanceType: 4 whenCreated: 20091215103053.0Z whenChanged: 20100510065727.0Z displayName: vuser1 uSNCreated: 1122529 uSNChanged: 1352342 name: vuser1 objectGUID:: LtWX7JjtpUO3s3EVCIg1sg== userAccountControl: 512 primaryGroupID: 513 objectSid:: AQUAAAUVlY9rWhrl0jyBPJSISQUAAA== sAMAccountName: vuser1 sAMAccountType: 805306368 userPrincipalName: vus...@domain.com objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=domain,DC.com msSFU30Name: vuser1 msSFU30UidNumber: 100029 So that's what that looks like. Should be enough, at least for uid resolution, or? BTW, I just noticed something in a previous message: 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: msSFU30GidNumber First, I assume that the last command should be setting ad_unixgroup_attr, not ad_unixuser_attr. I assume that's simply a transcription error, since your experiments seem to work. Yes, it was a transcription error. But my experiments have stopped working. This was after I deleted /var/idmap/db and restarted idmapd. I also replicated msSFU30Name to the GC. Now I get: # idmap get-namemap winuser:mand Querying DNS for SRV RRs named '_ldap._tcp.dc._msdcs' for 'domain.com' Found _ldap._tcp.dc._msdcs.domain.com 600 IN SRV [0][100] bdc2.domain.com:389 No namemap found in AD. This is how idmapd is configured: # svccfg -s idmap listprop config application config/list_size_limit count0 config/stabilityastring Unstable config/value_authorization astring solaris.smf.value.idmap config/machine_sid astring S-1-5-21-1373536303-522864990-3864964639 config/ds_name_mapping_enabled boolean true config/ad_unixname_attr astring msSFU30Name config/ad_unixgroup_attrastring msSFU30GidNumber config/domain_name astring elego.de rpcbind dependency rpcbind/entitiesfmri svc:/network/rpc/bind rpcbind/groupingastring require_all rpcbind/restart_on astring restart rpcbind/typeastring service filesystem-minimal dependency filesystem-minimal/entities fmri svc:/system/filesystem/minimal filesystem-minimal/grouping astring require_all filesystem-minimal/restart_on astring error filesystem-minimal/type astring service general framework general/action_authorization
Re: [cifs-discuss] idmap and SFU
Quoting Jordan Brown jordan.br...@oracle.com: 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 5.11 NexentaOS_134b i86pc i386 i86pc Solaris Both have showed the same behavior with regard to id-mapping. Setting up LDAP with the SFU attributes works fine for NFS, but I cannot figure out the CIFS side of things. I thought that something like: 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_unixgroup_attr=astring: msSFU30Group would work but, but it does not. 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: msSFU30GidNumber Seems to work one way: # idmap get-namemap winuser:vuser1 Querying DNS for SRV RRs named '_ldap._tcp.dc._msdcs' for 'domain.com' Found _ldap._tcp.dc._msdcs.domain.com 600 IN SRV [0][100] bdc2.domain.com:389 AD namemaps for winuser:vuser1 - unixuser:vuser1 - unixgroup:215 and # idmap get-namemap wingroup:vmware Querying DNS for SRV RRs named '_ldap._tcp.dc._msdcs' for 'domain.com' Found _ldap._tcp.dc._msdcs.elego.de 600 IN SRV [0][100] bdc1.domain.com:389 AD namemaps for wingroup:vmware - unixuser:vmware - unixgroup:11000 but, # idmap get-namemap unixuser:vuser1 Native ldap namemaps aren't active. Failed to get namemap info (Invalid argument). Shouldn't that be resolvable in AD? and, # idmap show winuser:vuser1 winuser:vuser1 - uid:2147491841 returns an epemeral uid. [_confused_] I would indeed expect that to work, but I can't say that I've tried it. The first thing that comes to mind as a possible problem is case sensitivity issues; when I look at my IDMU-based entries msSFU30Name is in mixed case, and that wouldn't tend to play nice with UNIX name services. Name-based mapping works, at least for uids, but would be too cumbersome to maintain in our environment. Has anybody gotten AD idmapping working with SFU? Recent emphasis has been on IDMU support using the UID/GID supplied by IDMU. (It might work for SFU too, but that wasn't a goal and hasn't been tested.) That was delivered in build 124. I'm pretty sure people have made the ds_name_mapping_enabled support work with SFU, but that mostly predates my tenure as custodian of idmap. -- Michael Anderson IT Services Support elego Software Solutions GmbH Gustav-Meyer-Allee 25 Building 12.3 (BIG) room 227 13355 Berlin, Germany phone +49 30 23 45 86 96 michael.anderson at elegosoft.com fax +49 30 23 45 86 95 http://www.elegosoft.com Geschaeftsfuehrer: Olaf Wagner, Sitz Berlin Amtsgericht Berlin-Charlottenburg, HRB 77719, USt-IdNr: DE163214194 ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] idmap and SFU
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 I am accessing the CIFS from a windows box, idmap is not able to get the info from the AD, even though it gets it when doing a get-namemap -- This message posted from opensolaris.org ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] idmap and SFU
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: msSFU30GidNumber Seems to work one way: # idmap get-namemap winuser:vuser1 Querying DNS for SRV RRs named '_ldap._tcp.dc._msdcs' for 'domain.com' Found _ldap._tcp.dc._msdcs.domain.com 600 IN SRV [0][100] bdc2.domain.com:389 AD namemaps for winuser:vuser1 -unixuser:vuser1 -unixgroup:215 and # idmap get-namemap wingroup:vmware Querying DNS for SRV RRs named '_ldap._tcp.dc._msdcs' for 'domain.com' Found _ldap._tcp.dc._msdcs.elego.de 600 IN SRV [0][100] bdc1.domain.com:389 AD namemaps for wingroup:vmware -unixuser:vmware -unixgroup:11000 but, # idmap get-namemap unixuser:vuser1 Native ldap namemaps aren't active. Failed to get namemap info (Invalid argument). Shouldn't that be resolvable in AD? OK, first: get-namemap and set-namemap don't actually do mapping. They get and set directory-based mapping data. That's only one input to the mapping process. To actually test the mappings you need idmap show. Second: Again, they don't do mapping. For AD mode, there are UNIX-name entries in the AD record, and those entries are used for both directions. Get-namemap on a Windows name retrieves the UNIX entries in a specified AD record. On the other hand, for Native LDAP mode there are Windows-name entries in a generic LDAP record, and get-namemap on a UNIX name retrieves those entries. and, # idmap show winuser:vuser1 winuser:vuser1 - uid:2147491841 returns an epemeral uid. [_confused_] So mapping isn't working. I believe that the problem is that msSFU30Name isn't exported to the Global Catalog, and the directory-based name mapping stuff requires that the data be visible in the Global Catalog. Here's an article that says how to make an attribute visible in the Global Catalog: http://support.microsoft.com/default.aspx?scid=kb;EN-US;248717 ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] idmap and SFU
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. I thought that something like: 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_unixgroup_attr=astring: msSFU30Group would work but, but it does not. I would indeed expect that to work, but I can't say that I've tried it. The first thing that comes to mind as a possible problem is case sensitivity issues; when I look at my IDMU-based entries msSFU30Name is in mixed case, and that wouldn't tend to play nice with UNIX name services. Name-based mapping works, at least for uids, but would be too cumbersome to maintain in our environment. Has anybody gotten AD idmapping working with SFU? Recent emphasis has been on IDMU support using the UID/GID supplied by IDMU. (It might work for SFU too, but that wasn't a goal and hasn't been tested.) That was delivered in build 124. I'm pretty sure people have made the ds_name_mapping_enabled support work with SFU, but that mostly predates my tenure as custodian of idmap. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
