<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="http://blogs.technet.com/utility/FeedStylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Time for an Active Directory Redesign?</title><link>http://blogs.technet.com/b/wincat/archive/2006/04/06/424452.aspx</link><description>Hi all... I'm Robert DeLuca, the Identity Management guy on WinCAT. 
 After a year or two of slowly dwindling requests for AD design reviews, there appears to be a growing trend among many of my enterprise customers - full Active Directory redesign.</description><dc:language>en-US</dc:language><generator>Telligent Evolution Platform Developer Build (Build: 5.6.50428.7875)</generator><item><title>re: Time for an Active Directory Redesign?</title><link>http://blogs.technet.com/b/wincat/archive/2006/04/06/424452.aspx#426396</link><pubDate>Wed, 26 Apr 2006 07:32:20 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:426396</guid><dc:creator>rdeluca</dc:creator><description>I think these are great ideas, but so far we've taken a different approach to the directory. Features like data validation/enforcement have been left to other Microsoft products while we focused on ensuring AD was a stable, reliable, secure directory platform.&lt;br&gt;&lt;br&gt;Integration between the file system and AD is a common request from NDS folks, but I think the issue runs deeper than the file system. It's an authorization/entitlement issue in general. Think of file services as a consumer of authorization information, just like any other application. We're looking at better ways of handling authorization, especially when you need to enforce and audit across a large globally distributed enterprise.&lt;br&gt;&lt;br&gt;So what does it really mean for something to be &amp;quot;done&amp;quot; in AD? Is it having a single console to manage these functions? Or is it storing the configuration information in the directory? Or are you saying the AD code itself should perform these functions? From an end-user perspective I suspect the requirement is somewhere between a single console and leveraging the directory for config data. &lt;br&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.technet.com/aggbug.aspx?PostID=426396" width="1" height="1"&gt;</description></item><item><title>re: Time for an Active Directory Redesign?</title><link>http://blogs.technet.com/b/wincat/archive/2006/04/06/424452.aspx#424506</link><pubDate>Thu, 06 Apr 2006 19:32:19 GMT</pubDate><guid isPermaLink="false">d5e57398-b9ef-4490-9955-07cbb4e4a80d:424506</guid><dc:creator>Ian Swartz</dc:creator><description>I'd like to see A/D do a lot of things that us 'Legacy' (i.e. those with Novell NDS experence) took for granted in NDS.&lt;br&gt;For example, why not use A/D to assign file and folder permissions. Then you could run a query against A/D and see what rights a user has to all files and folders in their domain?&lt;br&gt;You could use 'Aliases' to show a folder as more than one name (Although DFS sort of helps with this).&lt;br&gt;You should be able to see in user properties a history of when the user logged on/off. &lt;br&gt;The list goes on, but the MORE you can do through A/D the better.&lt;br&gt;DFS and Printer management should be A/D functions.&lt;br&gt;File replication should be done in A/D.&lt;br&gt;I think you get my gist.&lt;br&gt;A/D has always been more cumbersome to use than NDS ever was.&lt;br&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;&lt;img src="http://blogs.technet.com/aggbug.aspx?PostID=424506" width="1" height="1"&gt;</description></item></channel></rss>