[OpenIndiana-discuss] DNS Alias issue for CIFS - network, , path not found on Win7

[Robbie Crash]

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 at my-domain.local" unixgroup:users
> idmap add "wingroup:Domain Admis at 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:user at domain.tld  unixuser:user the FQDN is required
>> for the Windows user portion IE not just domain\user or user at domain, but
>> domain.com\user oruser at 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 at 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 need.http://support.microsoft.**com/kb/982860<http://support.microsoft.com/kb/982860> Disabling
>> signing will make MITM attacks easier.
>>
> Thanks. I was not aware of that aspect. Looking into it however leads me
> to the assumption that this is not the reason. The kb refers to Win7 and
> 2008r2 only, but the problem actually occurs worst on a certain XP machine.


SMB signing is enabled in XP as well, but different registry path:
http://support.microsoft.com/kb/887429

That being said, I don't know that this is going to be related.