Never mind that post -- I didn't find any documentation online regarding the functionality of that particular setting, but checking out some hard-copy reference made it clear that Auto Assignment was not the solution to this problem.  I should say that my gut feeling is that AD is properly set up.  Their IT department takes care of the whole thing, and I'm fairly confident it is not an oversight on that point.  Also, I undertook a pseudo-recursive double-click-after-double-click exploration through AD to see of what groups StudentServices was a member, but it indicated that it did not have any parents.

If LDAP will still provide further functionality or you feel it's an important area into which to look, I can start looking up the chain to get it installed.

Hey Mike -- skirting the LDAPBrowser issue one more time, we've had somewhat of a breakthrough.  We discovered the source for the role-wiping, but we have one problem remaining.

The original problem and its solution:

We're running two separate instances of the same portal via two separate websites and application pools.  One of the sites is intended for public end-users, the other is for intranet users.  They point to different domains, and we made a little fix that checks for the domain (instead of using an ip range) to force Windows auth when a user is on the admin.* site.

The problem seems to have been with the credentials/identity of the application pools.  One application pool (that intended for the admin site) has a domain account with Active Directory access.  The other application pool (for the public site) is using the Network Service account (local to the server, with no AD access).  Whereas we did not specify a username and password in the Admin > Authentication settings in DNN, it seems to be relying on the Application Pool credentials for accessing AD.  Because I’m working off-network, I’ve been testing on the www site, and we were having the clients test on the www site also, so when a user logs in the www site, the application pool Network Service identity tries to access AD to no avail and it wipes the roles for all the users.  Trying on the admin site, though, proves successful in that it does NOT wipe the roles that already exist, most likely because the admin site’s application pool identity has access to AD.

The remaining problem:

That said, though, we do have one problem:  although the roles are no longer wiped when users login through the admin site, they still are not allocated for the users unless we add them manually to the corresponding groups via DNN.  (Also, as a side note – if we manually add a user by the DNN interface to an AD-linked DNN role to which they do NOT belong in AD, at the next DNN login they are still in that role.  I do not know if this is desired behavior or not, but it seems given the previous issue we were tangling with, it might not be.)

Do you have any ideas on that problem (the main one—the side note is just an extra bite), or do you think it’s of the same/a similar origin?  Our solution at this point, as the "drop-dead deadline" is in 36 hours, is to manually add all of the users to DNN (those who have not yet logged on) and then manually add all of the users to their respective roles.

Thanks again for all of your help so far,

Zack

Without setting up a test environment similar to how yours is setup I'm not sure why roles wouldn't be getting assigned though what was happening on the public site sort of makes sense. I'll have to check to see just how much information NETWORK SERVICE can pull from an AD. IE: If it can get the groups but not see who's in them then it makes sense that users would be removed from the roles though I didn't think NETWORK SERVICE could pull any information from the AD (it should error out).

I'm not sure when I'll be able to get a test environment setup (work is nuts getting ready for students coming back in a few weeks) so I think your solution, while a real pain, may be the best one to use over the next 36 hours. If you look in the AD Fixes post one of the users did create a module that will bulk add/remove AD users and manage their roles (it's the 2nd or 3rd post in the thread). I don't know if his link is active anymore but it might make things easier for you.