ad syncronisation bug

[Dr Krall]

Hello,

wg 6.0.0 on win 2000 against 2003 server ad userdatabase.

I made two universal groups:
KB_SURF_HTTP,
KB_SURF_HTTP_FTP

When added another existing group, say groupX, to be a member of KB_SURF_HTTP, wingate inserted it in KB_SURF_HTTP_FTP instead.
After adding removing the membership, resyncronizing wingate i now have ended up in not beeing able to find this groupX in wingate at all.

I tried with restart wingate service, no effect.

[Dr Krall]

Another problem:

If renaming the KB_SURF_HTTP to KB_SURF_HTTP_Z all policies stops working because they are not renamed.

[adrien]

Hi

We will have to check the first issue in the lab. As for the second, does this mean you have group policies specified in GateKeeper/WinGate?

I am not sure if there is a unique ID associated with AD groups (may be) which we can use to determine if a renamed group is an old group renamed, or a new group entirely. We will have to check this one too.

Adrien

[Dr Krall]

Yes, i use policies to allow KB_SURF_HTTP to access http but not ftp and KB_SURF_HTTP_FTP to access both.

[Dr Krall]

Is this issue dead ?

[adrien]

Hi

We are still going through this in the lab here, Erwin will be sending you a reply soon.

Regards

Adrien

[Dr Krall]

Hello ,

Any ideas yet ?

/Ismo

[erwin]

Hi there

Apologies for not getting back to you sooner.

We have been testing this in the lab here and we have established that there is indeed a bug WinGate reflecting changes (your first discovery) in group membership being displayed and we are currently working to a resolution on this issue for the next maintenance release.

As for the other issue about renaming groups in the AD and the changes being reflected in WinGate Group/policy management we have reproduced this here but are still investigating this. We will keep you posted.

Once again sorry for the delayed reply

Regards
Erwin

[adrien]

I did some more testing on this about groups within groups.

the Win 2000 AD server I was testing on would only allow me to add a group to a group if the parent was a domain local group, and the child was a global group.

In these cases, WinGate showed the groups belonging to the correct groups fine.

We need to do some more testing with 2003 AD server - I am guessing this OS doesn't have that restriction on which types of groups can belong to which other types of group?

Adrien

[Dr Krall]

This has to do with the 'domain functional level'.
I use 'Windows Server 2003' functional level

Please read:
"http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/maintain/adusers.mspx#EFAA"

[adrien]

Hi

I did some more work on this today. It appears it is more related to the use of Universal groups. The network management APIs we are using don't appear to be aware of the existence of Universal groups, and cannot enumerate their membership properly.

When we call NetGroupGetUsers on a test group we have set up, it returns only user members who are users or global groups, not universal groups.

So it looks like we will need to do a bit more work, and use a different set of network management APIs to enumerate these types of group.

As far as I can see however, this only affects WinGate in terms of group membership for policies. Actual user authentication in testing here still works. Is this the problem you are having (group membership for policies)? I guess you can't change your AD to use global rather than universal groups? Not a great option I know.

We should also be able to synchronise with changed group names as well, but all these changes are not minor, and will take a bit of testing etc.

[Dr Krall]

Hello,

Well this explains a lot, i now understand some of the weird sequrity behaiviour i am getting.

I think i could live with this. Will reorganize the AD and make som tests.

Thanks !