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

Sebastian Gabler sequoiamobil at gmx.net
Fri Mar 8 10:09:44 UTC 2013


Hi Robbie,

thanks for your elaborate thoughts. I am trying to follow, so another 
round of comments from my side inserted

Am 07.03.2013 20:37, schrieb openindiana-discuss-request at openindiana.org:
> ------------------------------
>
> Message: 3
> Date: Thu, 7 Mar 2013 11:36:04 -0500
> From: Robbie Crash<sardonic.smiles at gmail.com>
> To: Discussion list for OpenIndiana
> 	<openindiana-discuss at openindiana.org>
> Subject: Re: [OpenIndiana-discuss] DNS Alias issue for CIFS - network,
> 	path not found on Win7
> Message-ID:
> 	<CAPVmm=bYgHyJKp+QdFP+gZxEaSX5gJuARbYNib_6J=e+pbZ51Q at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
>> >AD integration with the builtin CIFS server is dead easy. I've joined OI to
>>> >>2003/2008 and 2012 native functioning domains with no issue.
>>> >>
>> >The command "smbdadm join -u" runs w/o any problem. But when it comes to
>> >idmap I have suffered a major screw-up just two days ago that cost me
>> >dearly. As soon as the kerberos was configured, and * users and the
>> >often-mentioned basic Domain Users and Domain Administrators groups where
>> >added in idmap, no share including those with guest access could be
>> >accessed anymore. Messages was flooded with "smbd[1862]: [ID 801593
>> >daemon.error] smb_idmap_batch_getmappings: Mapping not found or inhibited".
>> >  I couldn't find a way to solve that issue.
>> >
>> >Even when I left the domain, idmap continued to amok. idmap and smb/server
>> >would hang with no way to kill it until I changed the workgroup to an
>> >ephimeral value and flushed idmap after another re-boot of the whole
>> >machine. This came with a serious but sneaking degradation of CIFS shares
>> >access, kicking in after app. 8 hours from when I initially had left the
>> >domain.
>> >
> I'm assuming you followed the Oracle docs on domain joining?
> http://docs.oracle.com/cd/E23824_01/html/821-1449/configuringoperationmodetm.html
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.

>
> 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.
> 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.
> 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.
>
> 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.
>
>
>> >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?
>
>
> 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  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.

>
>______________________________**_________________
>OpenIndiana-discuss mailing list
>OpenIndiana-discuss@**openindiana.org<OpenIndiana-discuss at openindiana.org>
>http://openindiana.org/**mailman/listinfo/openindiana-**discuss<http://openindiana.org/mailman/listinfo/openindiana-discuss>
>

>
> -- Seconds to the drop, but it seems like hours. 
> http://www.openmedia.ca https://robbiecrash.me 
> ------------------------------

Kind regards,

Sebastian




More information about the OpenIndiana-discuss mailing list