{"id":48,"date":"2012-11-06T01:58:19","date_gmt":"2012-11-06T09:58:19","guid":{"rendered":"http:\/\/blog.ls-al.com\/?p=48"},"modified":"2012-11-06T19:27:52","modified_gmt":"2012-11-07T03:27:52","slug":"solaris-idmap-problems","status":"publish","type":"post","link":"https:\/\/blog.ls-al.com\/solaris-idmap-problems\/","title":{"rendered":"Solaris Idmap Problems"},"content":{"rendered":"
When using the kernel enabled CIFS server on Solaris 11, we found that the idmap service picks Domain Controllers that are located across a WAN link, which cause two problems:
\nA) slow authentication; or even worse
\nB) idmap will use a server that disappears when a WAN link goes down which causes havoc<\/p>\n
After watching the debug logs I can see that idmap scans the SRV records in DNS to get a list of Domain Controllers in the forest.\u00a0 Even when config\/site_name<\/strong> (not a well documented setting) is set in the SMF properties for idmap, the discovery process still cycles through the whole list of DC's<\/strong> in the forest.\u00a0 If the first one is unreachable it keeps going until it finds one.\u00a0 The list of SRV records is pretty much random since Active Directory assigned a weight of 100% to each SRV entry.\u00a0 So in our case the discovery routine of idmap use basically a random server in a list of 21 Domain Controllers no matter where they live.\u00a0 As long as its reachable through LDAP.<\/p>\n If the idmap service would just use the DC's listed in the specific site<\/strong> we specify for this CIFS server this would be a much more stable service.\u00a0 It's possible this could be a bug that needs to be reported to Sun (Oracle) I am not sure.<\/p>\n My work around:<\/strong><\/p>\n In my case I made local firewall rules on the inferior Windows Domain Controllers to block the specific Solaris CIFS server from connecting to them.\u00a0 So the idmap logs will still show the unsuccessful attempts connecting to non reachable servers during discovery<\/strong>, but at least it will not be able to use them.\u00a0 Whereas without the firewall block idmap would happily attach to a reachable DC in India or Australia.<\/p>\n Log entries looks\u00a0 like this:<\/strong><\/p>\n ** Note:<\/em> Check what DNS shows in the forest.\u00a0 Our case 21 DC's:<\/strong><\/p>\n Set Debugging Higher. Play with these. All might be too high, especially in a working server:<\/strong><\/p>\n Refresh the service to reload configuration change:<\/strong><\/p>\n Set site_name :<\/strong><\/p>\n If the site name is not set the discovery process will complain that no site found.\u00a0 It does not really affect anything since it goes and use any DC in the forest anyhow but I would think if site is set the discovery should behave better.<\/p>\n Check the SRV record for US site as we configured in Active Directory:<\/strong><\/p>\n Check the CA site:<\/strong><\/p>\n Check if this service is running. Might be required:<\/strong><\/p>\n TODO:<\/strong><\/p>\n - Check how the Solaris ZFS appliance does this.\u00a0 It does not appear to suffer the same fate.<\/p>\n Links:<\/strong><\/p>\n http:\/\/docs.oracle.com\/cd\/E19082-01\/819-3194\/adsetup-2\/index.html<\/p>\n","protected":false},"excerpt":{"rendered":" When using the kernel enabled CIFS server on Solaris 11, we found that the idmap service picks Domain Controllers that<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[15,14],"tags":[],"class_list":["post-48","post","type-post","status-publish","format-standard","hentry","category-cifs","category-solaris"],"_links":{"self":[{"href":"https:\/\/blog.ls-al.com\/wp-json\/wp\/v2\/posts\/48","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.ls-al.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.ls-al.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.ls-al.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.ls-al.com\/wp-json\/wp\/v2\/comments?post=48"}],"version-history":[{"count":0,"href":"https:\/\/blog.ls-al.com\/wp-json\/wp\/v2\/posts\/48\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.ls-al.com\/wp-json\/wp\/v2\/media?parent=48"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.ls-al.com\/wp-json\/wp\/v2\/categories?post=48"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.ls-al.com\/wp-json\/wp\/v2\/tags?post=48"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}PS C:\\Users\\Administrator.DOMAIN> netsh advfirewall firewall add rule name=\"Block Solaris IDMAPD\" dir=In new remoteip=\"172.19.8.62\/32,172.19.8.64\/32,172.21.8.33\/32\" Action=\"Block\" protocol=\"Any\" Profile=\"Domain,Private,Public\" enable=\"no\r\n\r\nOk.\r\n\r\nPS C:\\Users\\Administrator.DOMAIN> netsh advfirewall firewall show rule name=\"Block Solaris IDMAPD\"\r\n\r\nRule Name:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Block Solaris IDMAPD\r\n----------------------------------------------------------------------\r\nEnabled:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 No\r\nDirection:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 In\r\nProfiles:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Domain,Private,Public\r\nGrouping:\r\nLocalIP:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Any\r\nRemoteIP:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 172.19.8.62\/32,172.19.8.64\/32,172.21.8.33\/32\r\nProtocol:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Any\r\nEdge traversal:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 No\r\nAction:\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Block\r\nOk.\r\n\r\nPS C:\\Users\\Administrator.DOMAIN> netsh advfirewall firewall set rule name=\"Block Solaris IDMAPD\" new enable=\"yes\"\r\n\r\nUpdated 1 rule(s).\r\nOk.<\/pre>\n
\r\n# pwd\r\n\/var\/svc\/log\r\n\r\n# tail -f system-idmap:default.log\r\nLDAP: frdc001.domain.com:389: Can't connect to the LDAP server\r\nfrdc001.sonosite.com: Can't connect to the LDAP server - Operation now in progress\r\nLDAP: dedc002.domain.com:389: Can't connect to the LDAP server\r\ndedc002.sonosite.com: Can't connect to the LDAP server - Operation now in progress\r\nUsing server<\/strong> usdc001.sonosite.com:3268\r\n<\/pre>\n
\nUnfortunately the \"Using server<\/strong>\" log entry is specific to SunOS 5.11 151.0.1.8 which I think translates to Solaris 11 Express.\u00a0 Even with debugging turned on for all, discovery or ldap I did not get the \"Using server<\/strong>\" entries on 5.11 11.0.<\/em><\/p>\n\r\n# dig _ldap._tcp.domain.com SRV +short\r\n;; Truncated, retrying in TCP mode.\r\n0 100 389 frdc001.domain.com.\r\n<snip><\/em>\r\n0 100 389 indc002.domain.com.\r\n<\/pre>\n
\r\n# svccfg -s idmap setprop 'debug\/all = integer: 0'\r\n# svccfg -s idmap setprop 'debug\/ldap = integer: 1'\r\n# svccfg -s idmap setprop 'debug\/discovery = integer: 1'\r\n<\/pre>\n
\r\n# svcadm refresh svc:\/system\/idmap:default\r\n<\/pre>\n
\r\n# svccfg -s idmap setprop 'config\/site_name = astring: US'\r\n# svcadm refresh svc:\/system\/idmap:default\r\n<\/pre>\n
\r\n# dig _ldap._tcp.US._sites.domain.com SRV +short\r\n0 100 389 usdc101.domain.com.\r\n<snip><\/em>\r\n0 100 389 usdc001.domain.com.\r\n<\/pre>\n
\r\n# dig _ldap._tcp.CA._sites.domain.com SRV +short\r\n0 100 389 cadc001.domain.com.\r\n0 100 389 cadc002.domain.com.\r\n<\/pre>\n
\r\n# svcs name-service-cache\r\nSTATE\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 STIME\u00a0\u00a0\u00a0 FMRI\r\nonline\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 Jun_04\u00a0\u00a0 svc:\/system\/name-service-cache:default\r\n<\/pre>\n