Frank Cusack wrote:
That is helpful. But then why doesn't this produce the result I want:
# idmap list
add winuser:*...@xyz.com unixuser:*
# idmap show -cv winuser:frank.cusack unixuser
winuser:frank.cusack -> uid:60001
Error: No AD servers
idmapd isn't finding your AD servers at all. This is what I'd expect from
the domain name issue.
# id frank.cusack
uid=501(frank.cusack) gid=500(staff) groups=500(staff)
Note that the result of 'id' is coming from ldap (via nsswitch) querying
AD, binding anonymously.
Yes.
a) idmap is not mapping to the unix uid associated with the username
Right, because it's not able to connect to the DC.
b) idmap *is* mapping to some uid yet i cannot mount the share
No, it's really not. If its caller is willing to accept the results, it's
mapping to 60001, user "nobody", but mostly it's just an error.
ephemeral meaning: won't be persistent across reboots?
The numeric user id (or group id) that is assigned does not persist across
reboots. However, that id is also never stored anywhere; what is stored is
the Windows SID that represents that Windows user.
that's ok as
long as files created get ACLs associated with the user's name/groups
and not with these ephemeral uids
That's right.
(or do we have to say uidNumbers, ugh).
Only in an LDAP context. In any other context, people will understand that
UIDs are numeric.
but since it's easy enough to have a unix uid associated with all windows
users i'd much prefer to have a mapping to a persistent uid.
Depends on the context. If you are already assigning (numeric) UIDs to all
of your users, and especially if you're using AD as your UNIX name service,
and if all of your users are in a single domain with domain-wide UID
assignments, yes. If, on the other hand, you have primarily Windows users
and so don't necessarily have UIDs assigned, or you have multiple UNIX
domains covered by your AD domain (so "fred" or 1234 might refer to
different people in different parts of your org), using ephemeral IDs and
SIDs can be a win.
I didn't try the "ad" provider since ldap is working fine otherwise. How
would the ad provider be able to map ephemeral uids though?
The ad provider maps ephemeral IDs by using idmap to map them to their
equivalent u...@domain names. It's roughly equivalent to
$ idmap show -c uid:<ephId> winname
... but as long as you're getting the "No AD servers" error, we're not even
coming close to the point where we need to worry about how the users are
getting mapped. We need to get talking to the AD servers first.
The AD server discovery process *does* have a fair amount of debugging
output, but I'll bet right now that at its base it says something about not
being able to make an LDAP connection to the server because of a "local
error". Making those cases easier to diagnose is probably the top non-fire
item on my to-do list.
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
