Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain
On Fri, Sep 2, 2011 at 4:12 AM, Marc Bevand wrote: > On my domain controller, I created an AD user account plus a keytab file for > this account using ktutil.exe, which was then copied to the Linux NFSv4 > client as /etc/krb5.keytab. This client has the standard Kerberos tools > installed and is "seen" as being a Windows AD user by any Kerberized network > service. > > I think you are right, the username must be carried in some earlier NFSv4 > packets I did not look at... Will inspect in more details later. If you have Kebreros creds issued by AD then you should be able to create files on a Solaris 11+ NFSv4 server and have the correct ownership show up (i.e., the Windows user's SID, or the Unix UID that you map it to, if any). However, ls -l and getacl on Linux may not work right at all. Linux has its own ID mapping story, and IIRC it's not really supported in the Linux NFSv4 stack (but don't quote me on that; instead RTFM and see if there's something you can do about this :). Nico -- ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain
On Mon, Aug 29, 2011 at 2:16 PM, Marc Bevand wrote: > Nico wrote: >> Given the name-based mapping rules that you give below, do you have a Unix >> user account called "myuser"? > > In this test, no, I did not have a Unix account "myuser". Therefore it is not > a bug in nss_ad. > > As Jordan concluded, not having a Unix account "myuser" is officially > unsupported, and my strange observation is explained by the fact there _is_ a > code path (affecting both tmpfs and ZFS, but Jordan did not say where > exactly) mapping myu...@example.com to nobody. I wish Oracle would fix this. > In the mean time I can live with having to create the local Unix account to > prevent files owned by nobody. Not speaking for Oracle today, but recalling what was and wasn't supported... This is the deal: LOCAL ACCESS (shell, desktop): must have Unix account, and if you want to use Windows accounts then you must use name-based mapping (or directory-based name mapping) to Unix accounts. Same goes for groups. REMOTE ACCESS via NFSv4 and CIFS: need not have a Unix account/group for every SID, heck, need not have any Unix accounts/groups besides the default ones. Remember, at the time we developed this Sun was aiming for a storage appliance that had no local access as such, therefore local access issues had a much lower priority. If you want local access then you are constrained by the fact that we did not finish Windows integration for local access, leaving you to map Windows security entities to Unix security entities. Regarding NFSv4 issues... It's critical to understand what the client is and what it supports. Very few NFSv4 clients (and servers) support more than a single domain for users and groups. Windows NFSv4 clients and servers can generally be expected to support Windows users and groups from across an AD forest (including trusted forests), and, perhaps, with additional mapping facilities, one or more Unix domains. Non-Windows NFSv4 clients and servers generally support a single domain. The only exception when I was at Sun/Oracle was Solaris, whose NFSv4 implementation could handle one Unix domain and all domains in a single AD forest (including trusted forests). Specifically, NFSv4 has two aspects relating to IDs and interop: subject credentials, and object ownership and ACL. For the former you can get interop from non-Windows clients to Windows and Solaris NFSv4 servers by simply using Kerberos credentials issued by AD -- this is because the IDs are embedded in the krb5 tickets in a way that's opaque to the client. For the latter you can only get interop between implementations that understand multiple domains, and specifically AD domains. Nico -- ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain
On Mon, Aug 29, 2011 at 6:58 PM, Jordan Brown wrote: > On 08/29/11 12:16, Marc Bevand wrote: >> I wish Oracle would >> fix this. In the mean time I can live with having to create the local >> Unix account to prevent files owned by nobody. > > As Nico said, we'd like to fix it too - or, rather, we'd like to add the > feature of allowing Windows users to log in - but there's a bunch of issues > and it just hasn't made it to the top of the stack. Hey now, I'm glad Oracle wants to fix this, but surely I don't speak for you guys ;) ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain
On my domain controller, I created an AD user account plus a keytab file for this account using ktutil.exe, which was then copied to the Linux NFSv4 client as /etc/krb5.keytab. This client has the standard Kerberos tools installed and is "seen" as being a Windows AD user by any Kerberized network service. I think you are right, the username must be carried in some earlier NFSv4 packets I did not look at... Will inspect in more details later. -- 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] Puzzling file ownership issue after joining AD domain
On 09/01/11 11:51, Marc Bevand wrote: Solaris 11 Express is snv_151a, and idmap does support the -V option. I set the debug/mapping property to 2, refreshed idmap, (and additionally ran "idmap flush"), unfortunately I see no trace in the log when my NFSv4 client logs in and creates a file. I know the debugging options are correctly enabled because I see lines being logged when running "ls -l" locally on Solaris on files owned by AD users. I looked at packet captures of the NFSv4 traffic and see no username like "myu...@example.com" being transmitted by the Linux client to the Solaris server, which is unexpected... Wait a second... how do you get a Linux system to log in via NFSv4 as a Windows user? I suspect that if the name is carried anywhere, it's in the session startup messages rather than in the actual "create" message. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain
Solaris 11 Express is snv_151a, and idmap does support the -V option. I set the debug/mapping property to 2, refreshed idmap, (and additionally ran "idmap flush"), unfortunately I see no trace in the log when my NFSv4 client logs in and creates a file. I know the debugging options are correctly enabled because I see lines being logged when running "ls -l" locally on Solaris on files owned by AD users. I looked at packet captures of the NFSv4 traffic and see no username like "myu...@example.com" being transmitted by the Linux client to the Solaris server, which is unexpected... -- 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] Puzzling file ownership issue after joining AD domain
On 08/30/11 14:50, Marc Bevand wrote: It did not work. No matter what nfsmapid_domain is set to (any-other-name.com or example.com), files created on the ZFS file system by my Kerberized NFSv4 client always end up owned by nobody. I even rebooted the Solaris server and the client after each change to make sure I did not forget to reload a service, or was not accidentally re-using cached data somewhere. Everything is so close to working with only Kerberos/AD... It is too bad that LDAP is still required for full integration. Foo. One of the big problems that we have in this area is that there are so many things that have to be configured just right for everything to work that there are many ways to fail. Some components have diagnostic information that can help, while others don't. I don't know exactly when Solaris 11 Express was in terms of our internal build numbers, and so I don't know whether you have the current idmap diagnostic features. Try "idmap show -cV uid:0" I'm not interested in the output, just in whether it complains about the V. If it doesn't complain about the V, try this: # svccfg -s idmap setprop debug/mapping = 2 # svcadm refresh idmap and then # tail -f /var/svc/log/system-idmap:default.log while you log in and create a file. If the NFSv4 parts of the system are running right, you should see trace results from mapping the name@domain that NFSv4 carries over to a (possibly ephemeral) UID. If you don't get any trace results, that's interesting. If you *do* get trace results, they may help to explain the problem. Unfortunately, there's no similar tracing capability in the NFSv4 part of the picture. When you're done, do # svccfg -s idmap setprop debug/mapping = 0 # svcadm refresh idmap to turn the output back off. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain
It did not work. No matter what nfsmapid_domain is set to (any-other-name.com or example.com), files created on the ZFS file system by my Kerberized NFSv4 client always end up owned by nobody. I even rebooted the Solaris server and the client after each change to make sure I did not forget to reload a service, or was not accidentally re-using cached data somewhere. Everything is so close to working with only Kerberos/AD... It is too bad that LDAP is still required for full integration. -- 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] Puzzling file ownership issue after joining AD domain
On 08/29/11 21:28, Marc Bevand wrote: So are you saying I should try after "sharectl set -p nfsmapid_domain=any-other-name.com nfs" and ownership should be handled correctly? I will try tomorrow. That might work. What *wouldn't* work in that configuration was any user that was only a UNIX user and was not a Windows user. Although this particular interaction (NFSv4 and AD) has some rough edges, it *is* at least a bit sensible. Domains define a space where a particular set of names is known. Your NFSv4 domain name setting says which domain your UNIX user names are known in. If you use the same names for NFSv4 and AD you are in a sense saying that the names are the same between the two, and normally (absent either setting the UNIX name service to use LDAP from the AD servers, or manually synchronizing the databases) that wouldn't be the case. The best thing to do to make that work right is to set the UNIX name service to use AD LDAP, so that everybody in that domain is using the same directory. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain
Thank you so much for all these insightful explanations Jordan. I might consider setting up LDAP eventually, but not now. Jordan wrote: > Is example.com your AD domain? Yes. And my NFS client is Ubuntu 8.04 with the krb5-user and krb5-config packages installed, a /etc/krb5.keytab file, and the share mounted with "mount -t nfs4 -o sec=krb5i solaris:/share /share". Non-root users on Ubuntu create their own Kerberos tickets with kinit(1) to access the NFS share. > If so, I believe this is intended to work, but I can't say that it's > been exercised as much as one might like. > > Also: if your NFSv4 domain has the same name as your AD domain, there's a > conflict of sorts. Names in that domain will be interpreted as UNIX names > (rather than as AD names) and so if they don't exist in the UNIX namespace > it's an error and they turn into "nobody". My NFSv4 domain is indeed the same; the system auto-detected it from the nameserver: $ cat /var/run/nfs4_domain example.com So are you saying I should try after "sharectl set -p nfsmapid_domain=any-other-name.com nfs" and ownership should be handled correctly? I will try tomorrow. -- 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] Puzzling file ownership issue after joining AD domain
On 08/29/11 12:16, Marc Bevand wrote: As Jordan concluded, not having a Unix account "myuser" is officially unsupported, and my strange observation is explained by the fact there _is_ a code path (affecting both tmpfs and ZFS, but Jordan did not say where exactly) mapping myu...@example.com to nobody. I didn't say because it didn't seem like it'd be a useful piece of information, but it's in the macro VOPXID_MAP_CR in usr/src/uts/common/fs/vnode.c, used in quite a number of file-oriented operations. It uses a dummy "nobody" credential when the file system in question doesn't advertise support for SIDs and the process credential has a SID. I wish Oracle would fix this. In the mean time I can live with having to create the local Unix account to prevent files owned by nobody. As Nico said, we'd like to fix it too - or, rather, we'd like to add the feature of allowing Windows users to log in - but there's a bunch of issues and it just hasn't made it to the top of the stack. Note that if you're careful you can configure your system to use your AD server as its UNIX LDAP server, which brings you closer to being able to support these users without manually creating UNIX users. With that explained, what about NFS (I use that too)? To summarize the tests I ran (when there is no Unix account "myuser"): 1. A file created remotely via CIFS (as myu...@example.com) ends up owned by myu...@example.com (good, as supported) Yes. 2. A file created locally (after su - myu...@example.com) ends up owned by nobody (unsupported scenario; caused by the code path mentioned by Jordan; but creating a Unix account myuser makes the file owned by myuser) Yes, this is what we've been discussing. 3. A file created remotely via NFSv4 (by a Kerberized NFS client authenticated as myu...@example.com) ends up owned by nobody instead of myu...@example.com (but creating a Unix account myuser makes the file owned by myuser) What explains #3? Is this a supported scenario? I assume not, given that the same workaround (creating a Unix account myuser) is required to prevent files owned by nobody. Is example.com your AD domain? If so, I believe this is intended to work, but I can't say that it's been exercised as much as one might like. Also: if your NFSv4 domain has the same name as your AD domain, there's a conflict of sorts. Names in that domain will be interpreted as UNIX names (rather than as AD names) and so if they don't exist in the UNIX namespace it's an error and they turn into "nobody". ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain
On 08/29/11 11:54, Marc Bevand wrote: This is correct. When the Unix account myuser exists: # id uid=0(root) gid=0(root) # su - myu...@example.com su: No directory! Using home=/ $ id uid=10111(myuser) gid=2147483691(Domain us...@example.com) When it does _not_ exist: $ id uid=2147483650(myu...@example.com) gid=2147483691(Domain us...@example.com) OK, good. So... as I've noted, using name@domain in a login-like context (including "su") is not supported and I was surprised that it was possible. Feel free to experiment, and I'm interested in the results, but you shouldn't expect any significant support in that area. The fact that you're able to get as far as you do, that the "su" works, is a bit of an accident and oversight, not a deliberate feature. We thought we'd made it so that you couldn't log in using name@domain style names. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain
Nico wrote: > Given the name-based mapping rules that you give below, do you have a Unix > user account called "myuser"? In this test, no, I did not have a Unix account "myuser". Therefore it is not a bug in nss_ad. As Jordan concluded, not having a Unix account "myuser" is officially unsupported, and my strange observation is explained by the fact there _is_ a code path (affecting both tmpfs and ZFS, but Jordan did not say where exactly) mapping myu...@example.com to nobody. I wish Oracle would fix this. In the mean time I can live with having to create the local Unix account to prevent files owned by nobody. With that explained, what about NFS (I use that too)? To summarize the tests I ran (when there is no Unix account "myuser"): 1. A file created remotely via CIFS (as myu...@example.com) ends up owned by myu...@example.com (good, as supported) 2. A file created locally (after su - myu...@example.com) ends up owned by nobody (unsupported scenario; caused by the code path mentioned by Jordan; but creating a Unix account myuser makes the file owned by myuser) 3. A file created remotely via NFSv4 (by a Kerberized NFS client authenticated as myu...@example.com) ends up owned by nobody instead of myu...@example.com (but creating a Unix account myuser makes the file owned by myuser) What explains #3? Is this a supported scenario? I assume not, given that the same workaround (creating a Unix account myuser) is required to prevent files owned by nobody. -- 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] Puzzling file ownership issue after joining AD domain
This is correct. When the Unix account myuser exists: # id uid=0(root) gid=0(root) # su - myu...@example.com su: No directory! Using home=/ $ id uid=10111(myuser) gid=2147483691(Domain us...@example.com) When it does _not_ exist: $ id uid=2147483650(myu...@example.com) gid=2147483691(Domain us...@example.com) -- 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] Puzzling file ownership issue after joining AD domain
On Wed, Aug 24, 2011 at 4:44 PM, Marc Bevand wrote: > I run Solaris 11 Express, successfully joined an AD domain with "smbadm join" > and with a proper Kerberos config like [1]. Can anybody tell me why files > created by these users locally (on Solaris itself, not through CIFS!) end up > with the ownership of 'nobody'? > > # id > uid=0(root) gid=0(root) > # su - myu...@example.com Given the name-based mapping rules that you give below, do you have a Unix user account called "myuser"? It's possible that nss_ad is returning an ephemeral ID here even though you have an actual name-based mapping to a Unix account. That'd be a bug, though I don't quite see how that would happen. > su: No directory! Using home=/ > $ id > uid=2147491842(myu...@example.com) gid=2147483650(Domain us...@example.com) This would indicate that no, you don't have a Unix "myuser" account. > $ touch /tmp/test > $ ls -l /tmp/test > -rw-r--r-- 1 nobody nobody 0 Aug 24 14:28 /tmp/test Right, tmpfs should not be able to handle ephemeral IDs, IIRC. > It doesn't even involve CIFS and the typical id mapping complexity... Is the > system treating the ephemeral IDs of domain users as a special case and > converting them to 'nobody'? My idmap policy is pretty standard: it is just > used to map a few domain users who have local unix accounts by the same name: The only components of the system involved here are: tmpfs, idmapd, the name services (specifically nss_ad, assuming you don't have any myu...@example.com in /etc/passwd!), and everything else that "su - someuser" would imply (e.g., a user shell). CIFS is not involved. The mapping to nobody would be made by tmpfs. We're probably missing some details though. > # idmap list > add wingroup:*@example.com unixgroup:* > add winuser:*@example.com unixuser:* > > The most puzzling thing is that this Solaris server is also serving a share > using native CIFS support (zfs set sharesmb=on xxx), and ownership of files > created by remote users through CIFS is perfectly correct. I only encounter > this problem when creating files locally (I was hoping to give my users SSH > access to allow manipulating the files locally...) As Jordan says, running Unix user processes as Windows user IDs puts you in uncharted territory -- I certainly wanted to get to where that would be supported, but when I was at Sun (then Oracle) we never got around to it, and so, though it is possible to run processes with ephemeral IDs as e/r/suid and e/r/sgid, this is not supported. There's a lot of system components that would require modification to make this work right, such as: tmpfs, utmpx/wtmpx, lastlog, nss_ad (which doesn't have, for example, _getgroupsbymember() support, IIRC), and so on. Local access to files with SIDs in their "security descriptors" is supported, but only from processes with non-ephemeral IDs for e/r/suid and e/r/sgid, and only when the files are on ZFS. Note that when I speak of "supported" I really mean that something was or was not supported when I was at Sun/Oracle. I can't speak to what is or isn't supported now, but given what Jordan has said I think it's pretty clear that either what you want is not supported or there is a bug in nss_ad(5). Nico -- ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain
On 08/25/11 16:12, Jordan Brown wrote: The ZFS behavior is easy to explain. If there's a mapping between the Windows account and the UNIX account, we use the UNIX account in file metadata. In fact, I suspect (and verification is left as an exercise for the reader) that in this case when you log in as name@domain, you will find that your process's user ID ends up as the normal UNIX userid, not the ephemeral ID. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain
On 08/24/11 20:06, Marc Bevand wrote: Yes, I have "ad": $ grep -w ad /etc/nsswitch.conf passwd: files ad group: files ad My problem is not caused by tmpfs, because I observe the same behavior with zfs. Hmm. That's odd. Something else that disproves your theory (sorry :D) is that tmpfs is perfectly capable of recording AD ownership: I can "chown myu...@example.com /tmp/file" as root (which makes sense because a filesystem only sees 32-bit UIDs; it doesn't care if they are ephemeral). Yeah, I guess that might well work. Like I said, this is uncharted territory. Even more puzzling: after creating a local Unix account 'myuser' matching the AD account name (so that idmap bidirectionally maps them), my commands end up with the file owned by 'nobody' on tmpfs but 'myuser' on zfs. Why does zfs behave differently when this local account exists? The ZFS behavior is easy to explain. If there's a mapping between the Windows account and the UNIX account, we use the UNIX account in file metadata. The tmpfs behavior... don't know. We "know" that tmpfs doesn't support ephemeral IDs, but as you say it might well not *need* to support them; if it just keeps the ephemeral IDs around they should be good until the system is rebooted. Actually, as a workaround, creating local accounts is fine for my needs. But I would definitely like an explanation of what is going on with these ephemeral IDs... I suspect Solaris has a code path that, sometimes but not always, intentionally maps them to nobody, when the right thing to do would be to not interfere with them (ie. pass them as is to the filesystem). Entirely possible. Although ephemeral IDs are a pretty general concept and the system comes close to supporting them across the board, they have only been tested and exercised in some relatively constrained scenarios. [ later ] ... and indeed, I've found the very code that does that mapping. I don't immediately see why ZFS is triggering that code; on its face, it shouldn't be. Anyhow, the summary is that while it's fascinating to see how far you can get with a shell that's logged in as a Windows user, a shell (or for that matter any process) running as a Windows user isn't a supported case, and "su as root" is a loophole that we hadn't thought of. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
Re: [cifs-discuss] Puzzling file ownership issue after joining AD domain
Yes, I have "ad": $ grep -w ad /etc/nsswitch.conf passwd: files ad group: files ad My problem is not caused by tmpfs, because I observe the same behavior with zfs. Something else that disproves your theory (sorry :D) is that tmpfs is perfectly capable of recording AD ownership: I can "chown myu...@example.com /tmp/file" as root (which makes sense because a filesystem only sees 32-bit UIDs; it doesn't care if they are ephemeral). Even more puzzling: after creating a local Unix account 'myuser' matching the AD account name (so that idmap bidirectionally maps them), my commands end up with the file owned by 'nobody' on tmpfs but 'myuser' on zfs. Why does zfs behave differently when this local account exists? Actually, as a workaround, creating local accounts is fine for my needs. But I would definitely like an explanation of what is going on with these ephemeral IDs... I suspect Solaris has a code path that, sometimes but not always, intentionally maps them to nobody, when the right thing to do would be to not interfere with them (ie. pass them as is to the filesystem). -- 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] Puzzling file ownership issue after joining AD domain
On 08/24/11 14:44, Marc Bevand wrote: I run Solaris 11 Express, successfully joined an AD domain with "smbadm join" and with a proper Kerberos config like [1]. Can anybody tell me why files created by these users locally (on Solaris itself, not through CIFS!) end up with the ownership of 'nobody'? # id uid=0(root) gid=0(root) # su - myu...@example.com su: No directory! Using home=/ $ id uid=2147491842(myu...@example.com) gid=2147483650(Domain us...@example.com) $ touch /tmp/test $ ls -l /tmp/test -rw-r--r-- 1 nobody nobody 0 Aug 24 14:28 /tmp/test Oh, wow, you're off in uncharted territory. You've got "ad" in your nsswitch.conf, right? "ad" (and so the names that it handles, like myu...@example.com) isn't intended for Solaris login. It's intended only to allow you to see and manipulate Windows identities using tools like "ls -l" and "chown". It takes care to prevent login by setting the encrypted password to "*NP*". However, you're using "su" as root, and so you're bypassing the password check and getting to a shell as a Windows user with an ephemeral ID. We've thought about supporting that case, but we know that there are a number of problems with it and we thought that people couldn't get there. What you're seeing is that tmpfs, the file system that supports /tmp, doesn't support Windows identities in its file metadata. If you were to do your experiment in a ZFS file system you would probably get the file metadata behavior that you expect. However, again, running an interactive shell as a Windows user is not supported and there may be any number of issues. If you want to have your Windows users log into your Solaris system, you need to arrange for them to have UNIX accounts, and you need to map the Windows identities to the corresponding UNIX accounts. Probably the best way to do that (though a little tricky) is to set up Microsoft's Identity Management for UNIX on your AD server and populate things like user IDs, shell selections, home directories, and so on in your AD data. You can then configure idmap to use IDMU (which is easy) and that will get your Windows and UNIX accounts equated. You would also need to configure the "ldap" name service switch back end to use the AD server, with schema mapping to match the AD server schema up with the schema that the "ldap" back end needs. You would also configure Solaris Kerberos to authenticate against AD, and configure Solaris PAM to use Kerberos. (Getting those right is tricky.) If you got all of that working, you'd have a pretty fully integrated environment. Your users would be able to use SMB from Windows and would be able to log in and get a shell using their "Pre-Windows-2000 logon id" and their regular password. ___ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
