Auth Server - AD problems - PLEASE HELP! I'M DOWN!

  • I have a ticket open with Juniper TAC, but I want to get this fixed so I’m looking to you guys for help too!

    Here’s the deal:

    I upgraded from 5.5r2 to 6.0 today and now nobody can login.  I even downgraded back and still nothing, so I went back again to 6.0 and still down.

    Client logs say:

    7-08-24 14:45:05 - ive - [] MURPHY\jhall(Murphy Employees)[] - Login failed. Reason: NoRoles
    Info 	AUT24326 	2007-08-24 14:45:05 - ive - [] MURPHY\jhall(Murphy Employees)[] - Primary authentication successful for MURPHY\jhall/Murphy AD from

    They do have roles assigned…

    If I go to the auth servers and test configuration I get:

    Either the server is not a domain controller of the domain or the Netbios name of the domain is different from the active directory (LDAP) name.

    On the Domain Controller I see some strange things like Event 27: ```
    While processing a TGS request for the target server host/, the account IVENAME$@FWMURPHY.COM did not have a suitable key for generating a Kerberos ticket (the missing key has an ID of 8). The requested etypes were 2.  The accounts available etypes were 23  -133  -128  3  1.


    Computer Account Deleted:
    Target Account Name: ivename$
    Target Domain: MURPHY
    Target Account ID: S-1-5-21-1891193558-681279342-996637233-4988
    Caller User Name: HOST/ivename
    Caller Domain:
    Caller Logon ID: (0x0,0x29798E01)
    Privileges: -

    even though ivename$ isn't even the name of the host specified in the auth server advanced settings.
    Right now nobody can log in using their AD account information.  I've tried rebooting, I've tried setting up a new auth server, etc.  I'm sure it has SOMETHING to do with the IVE appliance computer account not authenticating to the domain, but cannot find anything that will help me get it to work right.

  • :mrgreen:
    Well looks like this (6.0R3) has solved my role-mapping problems!! Well done JTAC. Got there in the end…

    Anyone still having problems with this issue?


  • Maybe that the WINBIND functinality did not work proper in your case.
    So -

    • delete the computer account for the IVE in Active Directory
    • use Domain Administrator on IVE Authentication Server for Active Directory (WITOUT Prefix!) - so dont use domain\Domainadministrator but ONLY Domainadministrator as Username in the Auth.Server Configuration
    • Let the IVE create a new Computeraccount for the IVE in Active Directory via saving the config (you will see the Computeraccount in AD when you refresh the view on your Active Directory Users and Computers Console. Maybe you will have to wait a few minutes till its visable - wait for replication.
    • When you want to map roles via Group-Membership, use the “SEARCH” Button in the “Server Catalog” Window on IVE.
    • When you finishe, do a policy trace with a testuser. In the policy trace log you will see how IVE searches in AD for the groupmembership. Behind each group you will see the “SID” of the Group. That means - it works properly.

    Thats how i did it - and it works stable since month.

  • Engineer


    i am not sure this is the compleet fix!

    because they told me it will be fixed in 6.0r3.1 (so ask them)


  • Time to bump this baby….

    Looking at the release notes for V6.0R3 I see the following…

    AAA - This release fixes an Active Directory based authentication issue that some customers have faced on upgrading to 6.0R1 and 6.0R2 from earlier releases. This issue affected those customers whose NetBIOS domain names were different than their DNS domain names. (52382)

    Could this be the fix for this problem? I’ve contacted JTAC and trying to book the downtime for our IVE ASAP to try this.


  • 😞
    FYI I’m still unable to upgrade. We do not want to rewrite our rule set. Are still waiting for JTAC who are still working on it. And giving us updates.

    Trying to get a demo got from distributer or Juniper so we can bench the problem easier in the environment.

  • OK, ladies and gentlemen, I FIXED IT! With the help of THIS holy thread!
    This problem really mady me SICK in my empty brain!

    No it works fine - i can authorize users from ALL domains who have trust relation to our domain.

    I will write the next days an “extra” big thread with detailed howto, so that others save time and nerves.

    With this OPTIMAL solution for AD-Authentication and Autorization, i DONT need any LDAP Server, i DONT need any Radiusserver.

    ALL i need is an Active Directory Authentication Server configured on the IVE and WINBIND. WINBIND is the key to true happyness with IVE and Active Directory!

    My mistakes have been:

    • on AD Auth.Server i confiured Admin Credentials as domain\adminuser , but i had only to use adminuser (without any prefix!)

    • in the server catalog, when choosing the AD-Groups where my vpn users are membersof, i had not to search them via LDAP - i only had to use the LDAP Name, and not the DOMAIN Name. What is the difference? Well - domain can have ANY name. But the LDAP Name is the first part of the domain DN, so if your domain is, then superb is the ldap name.
      So, on groups i had to configure on server catalog in IVE, i had to use ldapname/groupname, and NOT domain\groupname or domain/groupname.

    Now everything is PERFECT, and this is really the preferred way to use AD with your IVE.

    Detailed HowTo will follow!

  • When i enter domain\adminname, the authentication does not fail, but - as seen in policy trace - WINBIND failes, because the IVE cannot join the domain.

  • @spacyfreak:

    On AD Authentication Server, my mistake was that i gave at Admin Login domain\domainadmin. But it did not work, as long i gave the prefix domain. It only worked WIThOUT the prefix! Strange world!

    So in the Admin Username: field you give the username without the domain\ part and it works?
    Hmmm that’s what we have done. What happens when you put domain\adminusername? Does the authentication fail?

  • On AD Authentication Server, my mistake was that i gave at Admin Login domain\domainadmin. But it did not work, as long i gave the prefix domain. It only worked WIThOUT the prefix! Strange world!

  • Just to say we are up to the next line of JTAC…

    We are on 5.5R1 they have tsted it with 5.5R3 and it works. could it be the versions. Anyone else here having this problem on 5.5R1?


  • Try to use in AD Authentication Server configuration

    Filter memberOf

    and not

    Filter member

    That worked in my case. I had the same problem that no roles were assigned when using filter member.

  • Hi,

    You say nested groups, but thats not exactly the same problem we had but they may be related anyway. Today I had yet another AD auth problem (in another environment) with 5.5R3 which not happend in 5.3R10 which i just upgraded from….

  • Just wanted to put in a “Me To” to this forum whereby nested groups in AD are not resolved in 6.0r1 (worked just fine in 5). Also have a support ticket open with Juniper on this, have uploaded traces, kitchen sink etc but I think they are comming for my first born soon.  Just for reference the case number is Case #2007-0903-0207

  • I can’t read it with one of my accounts but with the other, anyway the kb-article is posted earlier in the thread as Reply #12 on: 2007-09-12, 21:40:53

    br / ahd71

  • @ahd71:

    I was able to use the workaround from KB9005.

    Strange I’m not authorised to read that article though I can read other IVE based articles….

  • Hi everybody,

    I was able to use the workaround from KB9005.

    Basically just changed the group name from NETBIOSNAME/GroupName to LDAPname/GroupName where LDAPname is the first part of the FQDN for the AD domain.

    I have informed JTAC about the problem and workaround.

    Thanks everybody for contributing to the workaround (and hopefully to the solution)

    br /ahd71

  • @Frac:

    is at the AD server settings:

    Kerberos Realm Name
    Specify the method to use to get Kerberos Realm Name for AD servers.

    => choose => Use LDAP to get Kerberos realm name

    Then everything worked.

    For me this is already how it is set. The problem for me is that it works perfectly pre 6.0R1 but stops working as soon as we upgrade to 6.0R1.


  • Engineer


    i saw that once to, i think the problem was that my domain was wrong! (like KB article was saying)

    i had “company.local” and it needed to be just "company"
    other thing i saw that could give problems (but not sure it was this error):

    is at the AD server settings:

    Kerberos Realm Name
    Specify the method to use to get Kerberos Realm Name for AD servers.

    => choose => Use LDAP to get Kerberos realm name

    Then everything worked.



    I do it with AD for authentication, and additional LDAP Server for Authorization. And it works fine.