On Fri, Apr 17, 2009 at 10:29:20AM -0400, Matt Feightner wrote: > I am running latest version of NexentaStor v1.1.7, and I have > experienced an ongoing issue where access to CIFS shares from Windows > is failing intermittently. > > I found the source of the problem during my testing yesterday. Share > access was failing from 1:32pm until 1:45:55pm. I noticed that when I > ran 'dmesg', I kept seeing idmap failures for Administrator. > > Here is output from /var/adm/messages: > Apr 13 20:21:46 dev-cask idmap[298]: [ID 873961 daemon.info] change > global_catalog=dev-vmfrdc1.liquor.dev port=3268 > Apr 13 20:21:46 dev-cask idmap[298]: [ID 873961 daemon.info] change > global_catalog=dev-vmbwdc1.bourbon.liquor.dev port=3268 > Apr 13 20:21:46 dev-cask idmap[298]: [ID 873961 daemon.info] change > global_catalog=dev-vmbstopdc1.bstop.liquor.dev port=3268
This says that idmapd found three GCs (global catalog servers). idmapd mostly does LDAP searches against the GCs, not the DCs (domain controllers). Any GC in the forest will do. So idmapd keeps a list and tries to use one GC at any time. idmapd is not necessarily all that smart at picking the "best" GCs -- it does prefer GCs in your "site" (an Active Directory concept), so make sure that you've defined sites and assigned each subnet to a site, that way idmapd will find your server's subnet(s)'s site(s) and pick GCs that are local to that site(s). You can also force idmapd to use GCs of your choosing by setting the config/global_catalog property of svc:/system/idmap:default (a multi- valued property, each value should be the fully qualified name of a GC). But I recommend you first make sure that your AD sites are correctly configured, particularly given the fact that you don't have full connectivity within your forest (surely there's enough connectivity for your GCs to synchronize, right?). > Apr 13 20:21:46 dev-cask idmap[298]: [ID 452674 daemon.info] change > domains_in_forest=liquor.dev > Apr 13 20:21:46 dev-cask idmap[298]: [ID 868507 daemon.info] change > trusted_domains=scotch.liquor.dev direction=bi-directional > Apr 13 20:21:46 dev-cask idmap[298]: [ID 868507 daemon.info] change > trusted_domains=bourbon.liquor.dev direction=bi-directional > Apr 13 20:21:46 dev-cask idmap[298]: [ID 868507 daemon.info] change > trusted_domains=bstop.liquor.dev direction=bi-directional So you have a forest (liquor.dev) with three sub-domains (scotch, bourbon and bstop). Is that right? > Currently, the only Windows DC accessible to Nexenta box (dev-cask) is > DEV-VMBWDC1.bourbon.liquor.dev -- both are in the same domain. So it > appears these timeouts are caused by Nexenta (OpenSolaris) trying to get to > an alternate DC (DEV-VMBSTOP1.bstop.liquor.dev) which is unreachable because > it is on a different subnet, on a different domain. Since it can't get > there, the id mappings fail, and hence the share access fails. > > Why is the Nexenta box trying to use a DC that's outside of its own domain? > Why does it need to get to all DCs? > The only servers that can talk to all DCs currently are the DCs themselves. > Do I need to open up communication to all DCs for the Nexenta box? It isn't talking to a DC -- it's talking to a GC (that happens to be hosted on another domain's DC). The GC is a special LDAP service running on AD DCs that are configured to be GCs. It serves a subset of properties of all directory objects which are instances of a subset of classes for all domains in the forest. In other words: you can only find users/groups in one domain's DC that are in that domain, but you can find all users/groups by looking in any GC for that domain's forest. idmapd takes advantage of this as a way to optimize its LDAP search activities. Nico -- _______________________________________________ cifs-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
