Thread Info
  • State Not Answered
  • Replies 33 replies
  • Subscribers 0 subscribers
  • Views 35192 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 [:)]
Parents
  • 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 BrucekConvergent
    I had been following the other post here and trying all the things you guys said to try.  The only thing that worked was using all CAPS for the domain.  So, it sure looks like that was the problem.

    At least that was the fix for it.
  • 0 in reply to TXGARobert@Home
    Alas, I've tried the 'all caps' method, but still get the 'joining the domain failed' message.
    Thanks for the tip anyway (I've tried many things, but until now, all CAPS wasn't one of them!)

    After the attempt to join, a computer account for ASG is automatically created in AD.
    I can ping my AD domain controller from ASG using it's full DNS hostname.
    Now on 7.090.
    I am continuing to try various 'combinations' of things, and will be sure to post here if I figure out my problem! [:)]
  • 0 in reply to AlexE
    @AlexE: After an unsuccessful joining attempt, please post the last 10-20 lines of /var/log/fallback.log.

    Thanks!
  • 0 in reply to tom_01
    Hi Tom,
    The following output is that produced following:
    Reboot of my ASG120 (7.090)
    Attempt to join my real domain. No output appears to have been generated.
    Attempt to join a non-existent domain. Last two lines of fallback.log
    Attempt to join my real domain. No output generated.

    output.txt

    Regards,

    Alex
  • 0 in reply to AlexE
    I have succeeded in joining my AD domain!

    The reason I'd previously failed, even when using CAPS to specify my domain name, was down to an incorrectly specified hostname in Management >> System Settings.
    After applying the 7.091 update, and attempting to join my domain, I noticed the following in the fallback.log

    2007:11:28-19:00:29 (none) [user:err] net: [2007/11/28 19:00:29, 0] libads/ldap.c:ads_get_dnshostname(2700)
    2007:11:28-19:00:29 (none) [user:err] net:   ads_get_dnshostname: No dNSHostName attribute!

    I hadn't seen this prior to 7.091, and it led me to discover the significance of a blank dnshostname attribute in the AD computer object's account. In turn, this led me to the ASG hostname setting. In my case, I hadn't specified the FQDN that I intended to use for the ASG. Setting this to 'firewall.chadfort.local' solved allowed me to successfully join my domain (chadfort.local).
    Now, I admit that the text shown alongside the 'Hostname' field in WebAdmin clearly states that the FQDN for the firewall should be specified.
    What confused me into not doing this is that it says that the FQDN should be resolvable in public DNS, and should point to the external interface of the system (It also suggests using a DynDNS hostname if available). However, as far as my understanding serves me, my ASG does not have a FQDN resolvable in public DNS. The FQDN I've specified is only resolvable in my company's private DNS, in which the ASG's FQDN points to its internal interface. This all seems to contradict WebAdmin's 'recommendations' for the hostname.
    Is my understanding a little off track?

    I use a VPN connection, in which I specify the actual IP address of my ASG's external interface.
    Could I also register ASG's 'private' FQDN with DynDNS along with it's external interface IP in order to save having to remember the IP address for VPN?
    Any comments would be appreciated.

    Thanks to all who contribute to this forum, especially the Astaro guys for 'listening' to the needs of the users!
  • 0 in reply to AlexE
    I suspect it's not the domain that has to be all caps, but that the ASG (after a successful join) is displaying the Kerberos realm, which is all caps. Mine joined no problem using all lower case, with a .local domain once I made sure that there was a dns record for the box in AD and that the ASG had the AD DNS server as a forwarder (previously I had it the other way around).

    That said, I don't know what the team may have changed/corrected, as I just updated to 7.101 from 7.100 this evening.
  • 0 in reply to lantegrity
    As a follow-up, at a client site I created a request routing entry for the internal clients so that requests to 'myinternaldomain.local' points to the internal SBS (AD) server. Then I joined the domain no problem.
  • 0 in reply to lantegrity
    After many retries, I solved the problem with this entry:

    Network - DNS - Request Routing - New DNS Request Route

    Domain:           home.local
    Target Server:  srv.home.local

    After applying this entry, I retried to activate SSO with upper case letters for the domain HOME.LOCAL - and it works.

    happy new year
    alfred
  • 0 in reply to Cowiz
    I have had this problem too (along with quite a few others since updating from 6.x to 7.1).
    The only thing that worked for me was the suggestion from Alfred to add the New DNS Request Route.
    That was the only thing that worked for me.

    Thanks bud.
Reply Children
No Data
Unfiltered HTML