I think after a while...the mapping disappeared.
The problem was that for some reason samba created that local logon domain from the smbpasswd information, and the lacking idmap configuration made it probably default to the same space, that idmap was assigning to the defined domain (I'd call that a bug....).
After declaring the local logon domain explicitely for idmap, and then waiting until winbind/idmap flushed the information, I think it worked again - but, before that happened I just changed the uid on the ADS and chowned everything on the file server.
Messy, but fast, and as the previously described fix was not taking immediately (no idea what one has to do to really-really flush the idmap cache), I had given up hope. Only later, when checking again, did I see that the local guest account was now mapped to a different uid.
Anyway, Samba/AD/idmap is a dark art, as the way of configuring it is silently changed every point release, the online documentation is a jumble, and mostly out of date, offline documentation (man etc) is incomplete....
I would consider what little knowledge I could gain from my experience already as a reason for someone to employ me, just for administering that. And I don't feel like I know anything. Even on the mailing lists there is very little traffic regarding this.
Going by the fact, that the configuration specs change every two years, I would not recommend it for production systems that are exposed to a network that is not known to be benign, because keeping up to date to avoid security scares is a major nightmare, and the number of interacting components (idmap alone is done on three levels: winbind, pam and the idmap module) makes it quite complex to debug.
But to me it appeared to be easier than using NIS.
Now that Samba 3.6 supports running as ADS, it may be easier though to get things running. Depending on how they resolved account mapping....
|
