This will be lengthy so apologies in advance.
I am having a problem getting a MAG 2600 to map roles using Active Directory.
I have two MAG-2600s setup in a cluster. I have cribbed a lot of the configuration from an existing MAG-4610 we have in our network. This device is stand alone.
I setup the authentication servers exactly the same except for one detail. On the 4610, the primary and secondary domain controllers are specified by IP address. I tried to do this with the 2600s, but the tests would fail. So when I entered the computer names for the domain controllers, that worked fine. (Go figure!) They are setup as Active Directory/Windows NT server types.
I setup the Admin realm exactly the same on all devices. The only exception is I left out one rule from the 4610 that will not be used on the 2600s. Everything is exactly the same. I have the rules mapping to the default roles for admins.
I did a policy trace on both the 4610 and the 2600 for logging in. The main thing I have found is that the 4610 starts matching against the Role Mapping in short order and the 2600 does not. Below are the relevant policy traces for each. I can provide the full trace if needed.
Originally the package running on the 2600s was 7.1R1. I read on the forums about active directory problems so upgraded to 7.1R5. The problems persist. The 4610 is running 7.1R3 (which purportedly has AD problems).
So does anyone know in advance why the 4610 will immediately start matching on the Role Mapping but the 2600s will not? And on a side note, does anyone know why the 2600 would fail a test on an authentication server when given the IP address?
Thanks in advance.
4610 Trace:
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:20:40 - pa-mag4610 - NTLogin(10.30.0.248, PA\jmehl, PA, juniperssl, no, , no, 1, 6, pa-mag4610 Computers)
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:20:40 - pa-mag4610 - Use any auth protcols
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:20:40 - pa-mag4610 - Performing Authentication using NTLMSSP ...
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:20:40 - pa-mag4610 - Authentication using NTLMSSP is successful
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:20:40 - pa-mag4610 - NTLogin done.
info - [10.30.56.112] - PA\jmehl(PA Admin)[] - 2012/02/20 15:20:40 - pa-mag4610 - Authentication successful to auth server "PA.CMS.LAN AD"
info - [10.30.56.112] - PA\jmehl(PA Admin)[] - 2012/02/20 15:20:40 - pa-mag4610 - Getting directory information from auth server "PA.CMS.LAN AD"
info - [10.30.56.112] - PA\jmehl(PA Admin)[] - 2012/02/20 15:20:41 - pa-mag4610 - GetUserGroups(10.30.0.248, PA\jmehl, PA, juniperssl, no, , no, 3, 6, pa-mag4610, Computers, 0)
info - [10.30.56.112] - PA\jmehl(PA Admin)[] - 2012/02/20 15:20:41 - pa-mag4610 - Rule Groups defined for the Realm are - PA/PA Tech Team==S-1-5-21-1961451770-2848275316-117541738-1162
info - [10.30.56.112] - PA\jmehl(PA Admin)[] - 2012/02/20 15:20:41 - pa-mag4610 - Rule Groups defined for the Realm are - CMS/Telecom Admins
info - [10.30.56.112] - PA\jmehl(PA Admin)[] - 2012/02/20 15:20:41 - pa-mag4610 - Rule Groups defined for the Realm are - CMS/Network Admins
2600 Trace:
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:09:26 - BMWMAG1 - NTLogin(pa1.pa.cms.lan, PA\jmehl, PA, juniperssl, no, , no, 1, 6, BMWMAG1 Computers)
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:09:26 - BMWMAG1 - Use any auth protcols
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:09:26 - BMWMAG1 - Performing Authentication using NTLMSSP ...
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:09:26 - BMWMAG1 - Authentication using NTLMSSP is successful
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:09:26 - BMWMAG1 - NTLogin done.
info - [10.30.56.112] - PA\jmehl(PA Admin)[] - 2012/02/20 15:09:26 - BMWMAG1 - Authentication successful to auth server "PA.CMS.LAN AD"
info - [10.30.56.112] - PA\jmehl(PA Admin)[] - 2012/02/20 15:09:26 - BMWMAG1 - Getting directory information from auth server "PA.CMS.LAN AD"
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:11:26 - BMWMAG1 - NTLogin(pa1.pa.cms.lan, PA\jmehl, PA, juniperssl, no, , no, 1, 6, BMWMAG1 Computers)
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:11:26 - BMWMAG1 - Use any auth protcols
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:11:26 - BMWMAG1 - Performing Authentication using NTLMSSP ...
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:11:26 - BMWMAG1 - Authentication using NTLMSSP is successful
info - [10.30.56.112] - jmehl(PA Admin)[] - 2012/02/20 15:11:26 - BMWMAG1 - NTLogin done.
To answer your questions, no Trusted Domains is not enabled. I changed the server names over to the IP addresses and it failed the test configuration. I changed them back to the server names and that test configuration passed. I am assuming for the last question you mean see the objects on the domain controller. Yes, those objects were confirmed by my server administrator.
To reiterate, I am trying to set this up as close to our 4610 as possible. The 4610 works.
Thanks
I am not sure what you would consider an excessive amount of time here. I can tell you that when I did test configuration on the authentication server, it took about one minute or more to test successfully. When I created role mapping rules, those went through pretty quickly. Attached are the full trace files.
I'm not sure if it helps for you, but I have seen similar behavior on the older SA.
Please check if the DC is able to make a DNS resolution of the IP from both MAG. IP to name and vice versa. It must be the internal IP not the VIP. This name must be the same which you use in the auth server config under advanced options. Per default you have there an cryptical name depending on the IP of the MAG. Please use there a FQDN which is resolvable from the DC.
Hope this helps
Joern
Hello Josh,
The policy trace shows the following:
info - [10.30.56.112] - PA\jmehl(PA Admin)[] - 2012/02/20 15:11:56 - BMWMAG1 - Timeout while group lookup
This seems to confirm the SA is not able to resolve the dns name of 'pa1.pa.cms.lan', but I would need debug log to confirm this issue. Since the IP address works, the immediate fix would be add the correct ip address in the Network>Hosts tab for 'pa1.pa.cms.lan' = 10.30.0.248. This should help avoid any DNS issue.
Hello Josh,
I realized that your first post state that the issue is reversed. In the working scenario, it says the the SA is connection the GC at 10.30.0.248. I do no see this in the non working scenario. If the short name works, this could mean that the response to the NetBIOS name could be responding with a different IP address than when you are inputting in the non-working scenario. It seems we'll need debug log to really confirm this issue. Please open a case so we can gather the proper logs to confirm this scenario
I have opened a case and am awaiting results. Thanks