Thread Info
  • State Not Answered
  • Replies 33 replies
  • Subscribers 0 subscribers
  • Views 35194 views
  • Users 0 members are here
Options
Suggested

[7.075] Joining AD does not work for .local domains [CONFIRMED]

AlexE
All,

After updating my ASG120 7.011 to 7.075, I was unable to login to webadmin using my usual Active Directory user credentials (which worked with 7.011)

I was able to gain access using webadmin's locally defined 'admin' user account to gain access.

I've tried redefining my 'Active directory domain admins' group in Users >> Groups. This group is specifed in Management >> WebAdmin Settings, under Allowed Users.
Still unable to access WebAdmin using my active directory credentials.

I had read that 7.075 included native active directory support, so I went to Users >> Authentication >> Active Directory to see if anything had changed (nothing as far as I can see).

I noticed that the domain specified under the Active Directory Single-Sign-On (SSO) was done so using it's NetBIOS name (contrary to the help text shown which suggests a dns domain name). I re-specified my domain using its dns name, but I receive a timeout message, and a message saying 'joining the domain failed'.

Now it appears that my ASG box is not communicating with Active Directory, because any attempt to access the internet via the HTTP proxy (which previously used Active Directory SSO), is resulting in a username/password request. Furthermore, authentication fails even if 'valid' credentials are supplied.

With my 7.011 installation, I had no problems with this. Is there something else I need to do with 7.075? What of the Active Directory 'native support'?


Regards,

Alex

P.S. I've found that general WebAdmin speed/performance has improved significantly with 7.075 [:)]
  • 0 in reply to tom_01
    Thanks for the info Tom.
    The time & timezone on my ASG box and my AD DNS server is set correctly, but I'm still unable to rejoin the domain.
    I suspect that the ASG box is unable to resolve the DNS domain name.
    My 'internal' domain is 'mydomain.local'.
    My AD server is called server-1. It is defined as Server-1 in Definitions >> Networks, together with it's IP addess. It is on the same subnet as the ASG internal interface.
    It is specified as 'Server-1' in Network >> DNS, on the forwarders tab.

    The reason I think there may be a problem with the DNS name resolution is that on Support >> Tools, under Ping Check, if I specify a custom hostname/IP address e.g. mypc.mydomain.local, I receive the following error:

    Ping check did not deliver a result, because of a probably non-existing ip address / hostname.

    I should point out that there is an 'A' record on my AD DNS server for mypc.mydomain.local. I can ping this host using it's FQDN from a DOS window on any client PC on my network, after performing an 'ipconfig /flushdns'.

    I've also tried clearing the reference to my AD DNS server on the Network >> DNS forwarders tab, and setting up a DNS request route on the Request Routing tab (mydomain.local -> Server-1). Same result when I try to ping from ASG.


    Regards,

    Alex
  • 0 in reply to AlexE
    If I try a 'DNS lookup' with the same FQDN hostname that failed the ping check (e.g. mypc.mydomain.local), the DNS lookup result shows the correct IP address i.e. the DNS name resolution was successful.

    If I do a ping check specifying 'custom hostname/IP address', using IP address of 'mypc.mydomain.local', the ping is successful.

    If I do a ping check specifying 'custom hostname/IP address', but specifying the DNS hostname 'mypc.mydomain.local', the following error is returned:
    'Ping check did not deliver a result, because of a probably non-existing ip address / hostname'.

    Traceroute behaves the same way.

    Perhaps I'm being distracted from the actual cause of the failure to join my AD domain, but I would expect ping and traceroute to work (They do in a DOS window for the same DNS hostname).
  • 0 in reply to AlexE
    Hi,

    .local domains are used for Multicast DNS, which we do not support. To work around this limitations, can you try the following:

    log in tou your ASG as root, and add the line 'mdns off' to /etc/host.conf? So the file should read like this:

    #
    # /etc/host.conf - resolver configuration file
    #
    # Please read the manual page host.conf(5) for more information.
    #
    #
    # The following option is only used by binaries linked against
    # libc4 or libc5. This line should be in sync with the "hosts"
    # option in /etc/nsswitch.conf.
    #
    order hosts, bind
    #
    # The following options are used by the resolver library:
    #
    multi on
    mdns off
  • 0 in reply to svens
    SVENS

    If you (Astaro) don't support .local DNS names, you're going to have major problems with many customers; Microsoft recommends in it's training materials that LAN AD setups use .local as the domain suffix (indeed, to get my MCSE I had to learn this many years ago).  Every customer we support has their AD setup this way, as well as customers we have evaluate the Astaro product.  As far as I know, using .local as your AD domain suffix does not necessarily mean one is using the mDNS protocol.  See http://en.wikipedia.org/wiki/.local for an example of why / how the industry commonly uses .local as a domain suffix.  I recommend that this behaviour be corrected, or else the product will not work properly with many AD implementations.  You don't need to support Multicast DNS; but if your DNS implementation / SSO implementation rejects the usage of .local domains, we will have issues.  Not many admins are going to be willing to rename their domain suffixes in Windows AD, given the aggravation that goes with that procedure (have done it, it is not pleasant on large networks).  Perhaps adding a checkbox to enable / disable mDNS support is in order...

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    Agreed, especially MS Small Business server uses .local by default...
  • 0 in reply to Simon Shaw
    Indeed Simon, good point... I just remember having it beat into my skull by every MS Whitepaper, etc...  While the .internal option mentioned in the Wiki article I posted would work, renaming a domain just for this would be painful in many environments, making it a non-starter.

    CTO, Convergent Information Security Solutions, LLC

    https://www.convergesecurity.com

    Sophos Platinum Partner

    --------------------------------------

    Advice given as posted on this forum does not construe a support relationship or other relationship with Convergent Information Security Solutions, LLC or its subsidiaries.  Use the advice given at your own risk.

  • 0 in reply to BrucekConvergent
    It's  a "bug" in the glibc binaries we use. We're gonna switch it off.

    Thanks guys.
  • 0 in reply to BrucekConvergent
    SVENS

    If you (Astaro) don't support .local DNS names, you're going to have major problems with many customers;


    Sorry, should have pointed out in my reply that this doesn't mean we don't
    want to support it - it is just right *now* not working because libc threats
    this kind of domain special.

    I've made a entry in our bugtracking system yesterday to remove this limitation. Just wanted to let you know about a workaround for the time
    being [:)]
  • 0 in reply to svens
    Thanks all for the continual updates about this. I'm using Small Buisness Server which is why I've gone for the .local domain. I'm happy to do the host.conf mod for now, but ASG's shell warns me that any mods by 'root' will void my support agreement. Can I assume that this particular mod is 'allowed'?
Unfiltered HTML