Blog
First blog
10/08/2010 08:13Our new blog has been launched today. Stay focused on it and we will try to keep you informed. You can read new posts on this blog via the RSS feed.
———
difference between ADS and NDS
10/08/2010 06:58
Table 1. Comparing Active Directory to NDS by requirement
|
Requirement |
Active Directory |
NDS |
|
Scalability without Complexity |
· Partition boundary is a Windows 2000 domain to enable direct access to all objects in a domain · Partitions use indexed data store for fast retrieval · Designed to hold millions of objects · Optimized replication between sites and over slow network links · Global Catalogs are updated simultaneously with other replication cycles to ensure low latency · Single data store and access methods for partitions and catalogs |
· Partitions are not indexed · Novell recommends a maximum of 1,000 objects per partition and that partitions should not span WAN links · Administrators must manage partition sizes and restructure partitions as they fill up · Searching for objects directly across partitions requires tree walking · Different data store for partitions and catalogs · High catalog latency since catalog is rebuilt only at scheduled intervals (default is 24 hours) |
|
Internet Standards Support |
· Implemented as a native LDAP server that requires no request translation · Consistent interpretation of access control rights when access is through LDAP · Provides LDAP-based access to all features · Full namespace integration with DNS to simplify object location and access |
· Provides LDAP support through server-based interface that must be installed on NDS servers individually · LDAP requests must be translated to NDS formats · Limited LDAP-based access to NDS features · Different naming syntax for LDAP access versus access through NDS APIs · Access rights interpreted differently when access is through LDAP versus NDS APIs · No namespace integration with DNS makes object naming and location more complex |
|
Flexible Security Services |
· Provides support for popular security technologies such as Kerberos and Smart Cards · Catalog enforces object- and attribute-level security · No restrictions on security groups that span partitions (domains) |
· Lacks support for Kerberos and Smart Cards · Catalog does not enforce object- and attribute-level security within the catalog database · Novell recommends that administrators minimize the use of groups that span partitions |
|
Support for Synchronization and Consolidation |
· Provides the scalability required to consolidate large directories without administrative complexity · Built-in LDAP-based change history interfaces facilitate use as a metadirectory platform · Catalog architecture enables fast, efficient query of large number of objects · Will be used by Microsoft products such as Exchange 6.0, MSMQ 2.0, MCIS 3.0 |
· Partition size restrictions limit use for directory consolidation · Provides no formal way to request change history information; requires customized synchronization agents · Catalog architecture forces tradeoffs between speed and consistency with underlying partitions · Not used by Novell's GroupWise product for account management and address book functions |
|
Comprehensive Development Environment |
· Provides COM-based Active Directory Services Interface (ADSI) for simplified development · JADSI supports access from Java applications · Provides the scalability required to ensure that applications can store, access and manage millions of objects without application-level complexity · Provides LDAP-based access to all features |
· No ADSI implementation for use by applications running on NetWare · JNDI supports access from Java applications · Applications must work within partition limitations · Limited LDAP-based access to NDS features |
Table 2. Comparing Active Directory to NDS by role
|
Role |
Active Directory |
NDS |
|
User and Network Resource Management |
· Provides the scalability required to store, locate, and manage large numbers of objects efficiently and without administrative complexity · Catalog architecture enables fast, efficient query of large number of objects · Global Catalogs are updated simultaneously with other replication cycles to ensure low latency · Designed to optimize replication traffic across wide-area network links |
· The number of partitions required by NDS to hold expected numbers of objects slows access and increases management complexity · Catalog architecture forces tradeoffs between speed and consistency with underlying partitions · High catalog latency, since catalog is rebuilt only at scheduled intervals (default is 24 hours) · Partitions that span wide-area links not recommended by Novell |
|
Security Authentication and Authorization Services |
· Provides support for popular security technologies such as Kerberos and Smart Cards · Catalog enforces object- and attribute-level security · Scales to supports large numbers of Extranet users · DNS integration simplifies object naming and location through Internet protocols |
· Lacks support for Kerberos and Smart Cards · Catalog does not enforce object- and attribute-level security within the catalog database · Partition size limits complicate Extranet use · No namespace integration with DNS makes object naming and location more complex |
|
Centralized Directory Management |
· Provides the scalability required to consolidate large directories without administrative complexity · Built-in LDAP-based change history interfaces facilitate use as a metadirectory platform · Catalog architecture enables fast, efficient query of large number of objects |
· Partition size restrictions limit use for directory consolidation · Provides no formal way to request change history information; requires customized synchronization agents · Catalog architecture forces tradeoffs between speed and consistency with underlying partitions |
|
Directory-Enabled Infrastructure and Directory-Enabled Applications |
· Strong support from leading vendors · Windows NT provides a rich development environment that is supported by many tools · Provides the scalability required to ensure that applications can store, access and manage millions of objects without application-level complexity · Provides LDAP-based access to all features |
· Support from many leading vendors missing · NetWare provides a limited environment for application developers · Applications must work within partition limitations · Limited LDAP-based access to NDS features |
———
managed and unmanaged
09/08/2010 23:53
An unmanaged switch is a glorified hub. It means that the switch does its thing with no user interaction. For most people, that's quite all right. The switch's benefits over a hub are full bandwidth to each port, rather than smushing all the data over all the ports like a hub, and dealing with collisions. A Managed switch has its own IP address, and has a telnet and maybe a web-based interface to monitor and secure access to each port on the switch. A managed port can have VLANs, which effectively break up different ports on a switch into different switches. This can be useful when you have a lot of ports but you'd like to, forinstance, separate direct connection to the Internet for a few computers, from the rest of your local area network. A managed switch can tell you about excessive usage on certain ports. It can be used to limit the number of IP addresses that one port can service. This is important if you want one computer for one port, forinstance. It makes sure nobody plugs a hub into a wall and shares off more connections without talking to the administrator first. A managed switch can also be used to enable or disable specific ports without unplugging a cable. This pretty much scratches the surface of what a managed switch can do for you. There is also logging ability, traffic management, and a lot more. But if you never need any of this, an unmanaged switch is adequate for many businesses.
———