First off I'm an LDAP and network guy don't know much about AD. Working with our AD admin to authenticate/authorize(AD Groups) off our enterprise AD with multiple domains.
AD admin are concerned about this domain admin and the rights requirements.
And it talking about computer accounts and creating writing computer objects?
Can someone breakdown for me and my AD admin what is really needed and what this account is doing?
Also any tips for multi-domain AD authentcation, right now I can't get the VPN to see the users groups.
working with VPN 7.1, AD 2008 and right now a full domain admin with no restrictions.
Appreciate any help you can provide.
Information on the requirements can be fount at http://kb.pulsesecure.net/KB2624.
If you are using multiple domains and you want to use just one AD server instance, you will need to be an enterprise admin rather than domain admin. If this is not possible, there is no benefit to using the AD/NT server instance compared to LDAP (which is overall more flexible and you will probably be happier with in the long run).
What type of errors are you seeing? Or is the problem that you are only seeing groups for one domain and not all of them?
In order to get group information, the AD server requires the IVE to create a computer object that it deletes and adds every 6 hours.
I'm seeing "GetUserGroups Finding user sid of user failed. user 'JSMith' does not exist
I can authenticate fine, it just doesn't see any groups attached to my userID.
What's the computer object used for?
Is this a group on the same domain as the user? The message indicates, typically, either the join domain operation failed or the group is on another domain that the IVE can't connect against. Does this happen with both username and domain\username at the login screen?
The computer object is on the domain in order to have a presence to retrieve group information; it is a requirement by MS. If you do not want to have this in place, you will need to use the LDAP server instance on the IVE (which is more powerful for you as an admin anyway).
A stripped-down service account as described in KB2624 definitely works, I just implemented an SSL VPN using one of those last week.
We did run into one gotcha: The AD admin had restricted the account to be able to log in to the DCs only, and as a result the account could not get group information. We set it back to be able to log in to "any" device, and that fixed it. It's possible that just giving it rights to log in to the created SSL VPN machine is enough, we did not test.
As for why all those rights are necessary: As has been stated, that's imposed by MS. Without those rights, the SA cannot join the domain, which means it can't query groups; and without those rights, the SA cannot change user's passwords on their behalf.
I typically prefer native AD over LDAP integration. It seems that SecureMeeting integration is smoother w/ native AD - but it's possible I haven't seen a "properly set up" LDAP integration yet.
tbehrens, thank you for the confirmation and external support of what is happening.
What type of failure are you seeing with LDAP and Secure Meeting that you don't see with AD/NT? I have only ever seen better experience with LDAP.
Thanks all for the feedback.
My setup has my vpn groups in one domain but my users are from various domains. I had Trust and everything checked and could authenticate but could not get groups to be read.
Policy trace is a great tool but I finally used the tcpdump tool and saw that the VPN was doing a DNS query on the domain with the wrong domain name. corp.companyname.com instead of corp.internal.companyname.com. I added internal.companyname.com to my domain name list and everything started working.