Better Active Directory Integration/awareness
Updated: 01 May 2010 | 3 comments
Status:
Reviewed
We would like to see that SEP leverages real Active Direction integration. SEP lacks the ability to add AD security groups as administrator which forces us to add every single SEP admin to the console and link them to their respective AD account.
We also would like to see more AD awareness using the reporting website. Now every user that needs access to the reporting site needs to login with their credentials regardless the permissions granted in IIS. Using the Windows credentials of the logged on user would help to bypass the login screen of the reporting site.
idea Filed Under:
Comments
Yes...pass my Windows creds
Yes...pass my Windows creds through to SEPM so I don't have to log on to SEPM (or reporting web site) at all. And that will also fix the username case-sensitivity nuisance.
But please, Symantec, make sure it WORKS...I enabled AD authentication in MR3 MP-something on a system and after a short time, was no longer able to authenticate in SEPM. Various utilities & SQL scripts to re-enable SEPM auth and set the default credentials did not work. Best Symantec support could do for me was tell me to uninstall SEPM, delete the database, then reinstall SEPM and rebuild everything from scratch.
Which I did, and it worked, but it's a heckuva solution. I've been afraid to use it ever since.
this is what we need... hope
this is what we need...
hope this gets implemented..
thanks..
Nel Ramos
Yes, place this idea on SEP feature enhancement roadmap...
I know that we can configure SEPM administrator to authenticate via AD by tying the SEP admin ID with the respective AD user ID.
Problem is for large and dynamic environment, such as helpdesk support with frequent turnover, the SEPM admin user list will need to be updated frequently. Hence, the creation/modification of SEP admins on a “per-user basis” as mentioned above can be tedious.
What would be good is if the respective SEPM admin user (and hence its role) can also be associated based on AD “group”... this way AD users can be added/removed to AD group membership and no changes is necessary at SEPM side. Plus if a SEPM admin role needs to be updated, we just update one (1) SEPM admin user and all the associated AD group users will have the same role... no need to update individual SEPM admin user. Does that make sense? :-)
Would you like to reply?
Login or Register to post your comment.