No problem, I'm not sure that I'm helping much unfortunately.
Please see my comments...
I was using information from there, indeed.
I left out this part *Become an administrator, obtain the
solaris.smf.value.shares and solaris.smf.manage.shares RBAC authorizations,
or use the SMB Management RBAC profile. *This was because I was running as
root. Even now after reading it for the second time, I would not understand
why it would be required to obtain any further roles here.
The whole thing actually changed when I found some different blogs that
recommended to add express idmap rules. I wonder why the above Sun/Oracle
blog leaves that part out. Basically, I added
idmap add winuser:*@my-domain.local unixuser:*
idmap add wingroup:Domain Users@my-domain.local unixgroup:users
idmap add wingroup:Domain Admis@my-domain.local unixgroup:staff
Do you (or anybody else reading this) have an idea when to put (always?)
express idmap rules? Many how-tos leave out this aspect altogether.
These mappings have been removed (and the kerberos config reverted) when I
left the domain. In spite of that idmapd continuing to log errors like this:
pdc.fqdn: additional info: SASL(-1): generic failure: GSSAPI Error:
Unspecified GSS failure. Minor code may provide more information (Client
not found in Kerberos database)
Even disabling idmap, deleting the db files and enabling idmap did not fix
that. So far I found no way to resolve that behaviour. I am also not sure
which configuration leads idmapd to continue to look for clients in the
domain after I dropped that.
What you're experiencing requires more knowledge than I have about idmap,
sorry.
I've always used explicit idmappings, but I'm not sure if that's required
or not.
In my experience, idmap failures are a result of only a few things:
1. The username/group is misspelled somewhere in idmap. Verify in idmap
list that it'swinuser:u...@domain.tld unixuser:user the FQDN is required
for the Windows user portion IE not just domain\user or user@domain, but
domain.com\user oru...@domain.com.
As far as I understand the above mappings should be ok, syntax-wise.
Yes, as long as you're not just using winuser@my-domain or
my-domain\winuser that should be fine.
2. Connections to the DC are failing either because of networking issues
or
because kerberos wasn't happy about something. Usually clock skew.
ntpdate pdc.my-domain.local is failing, but ntpdate -u is working against
the pdc. Clock should be ok. The pdc allows access to the DC services on
its firewall. I double-checked if the errors persist disabling the Windows
firewall, which was the case.
Why is it failing when you explicitly ask for the DC by DNS name? Is your
/etc/resolv.conf pointing to your DC first, and does it contain your local
domain names? Something like:
domain domain.local
search domain.local
nameserver 172.16.0.10
nameserver 172.16.0.11
3. A problem with the Windows user account, locked out/must change
password
at next logon/expired password
Nope. the errors were on accounts that are active.
4. DNS on the OI box being pointed somewhere other than a GC DC.
nslookup was running fine.
Check idmapping with idmap show -cV uid:UNIXUID to see what's happening
when idmap tries to do the lookup.
It said basically the same as in messages, and did an ephimeral mapping
that was cached.
So you received the same error about the mapping not being found/being
inhibited? Does that happen with all users you're trying to map?
Is the OI box able to look up Windows hosts by shortname?
Nslookup is ok on hostname and fqdn, if that's what you mean.
That's what I meant.
What is serving DNS for you?
The AD PDC.
Windows box? What version?
2008r2 64 bit Enterprise
Are you using WINS?
Not on OI, not on the DCs
Do you have NetBIOS enabled?
No
Do the clients know this?
I was not aware that this would be anything I should care about in a flat
network with clients XP SP3 upwards. My understanding was that it would
default on IP/DNS, and as there is no WINS on any of the file servers that
seemed logical to me. Did I miss anything here?
Windows will enable NetBIOS by default, and while Windows does use DNS
first, I've found that NetBIOS will still be used rather frequently. But
no, it shouldn't be an issue. Try disabling it on the problematic network
connections just to be sure lookups aren't for some reason failing over.
You can check your NetBIOS cached lookups by doing* nbtstat -c *on one of
your Windows clients that's having issues, *nbtstat -a OIBOXNAME *will show
you if you're able to resolve it by NetBIOS name.
See if disabling SMB security signing checks on a couple clients
eliminates
the issue. Office is particularly finnicky about this, and I have no idea
why. The registry changes in the Workaround section of this technet
article
will do what you
