> Are you saying there's another copy besides idmap.db? I'd not seen evidence
> of that.
No, but even if an object is already in the cache, it still seems to be
updating the UID. It doesn't seem to be the case that an entry in the idmap
cache is a static entry. Either that or the cache timeout settings just aren't
actually being used correctly (it is odd that this is changing every 10 minutes
- which is the default cache time).
> The hard part is finding one person who understands the internals of 3
> systems well.
They shouldn't really need to; OS X uses LDAP natively if you use OS X Server
(uncommon) so that would just work straight away, no problems there. In terms
of what we though most of the time Mac users will be accessing with Active
Directory credentials (because that's what enterprises tend to use these days).
> Given a program which will run on OI and return a text file w/ the current
> set of user IDs in the host domain, the rest is trivial. It's a non-blocking
> fork-exec of the update program. On a rare event it's as non-invasive as it
> gets.
The thing is that the whole problem with Active Directory is that (natively) it
doesn't have user IDs, it has SIDs - so you need to look up the SID and then
generate a UID. This is what winbind and Mac OS X do and importantly their
mappings are automatically generated, but static. So if user jbloggs logs into
an OS X system bound to AD, he gets a UID generated for him, and that will
always be his UID (on a Mac bound to that AD - it's generated based on the
SID). The problem with ephemeral IDs is the ephemeral part! If you could just
have an idmap setting which was basically:
use IDs 50000-75000 for AD users
that would solve the problem, once an AD user access the system they get
assigned a fixed UID. As mentioned OS X is slightly more clever as the UID is
generated procedurally from information from the AD, but that would be nice,
rather than critical. Basically if you could have idmap so it would do:
S-1-5-21-422489907-454740634-3148902543 >> 2147483650
with the Windows SID on the left and the UNIX UID on the right, and have that
not change, that would be it. You can do that now by doing name based
mappings, so you can get:
S-1-5-21-422489907-454740634-3148902543 >> name-of-local-user
but it isn't automatic and it's a bit inflexible. You could write a bash
script that did:
- LDAP query of AD to get user and group names
- Create matching users and groups on Oi system
- Create static maps between AD users/groups and Oi users/groups
I wouldn't think that would be fast though, and I wouldn't know the best way of
triggering it.
James.
_______________________________________________
OpenIndiana-discuss mailing list
[email protected]
http://openindiana.org/mailman/listinfo/openindiana-discuss
