Blog Entry

jjaimon's picture
blog
Reads:

11887

Score:
2
2
1
 
Comments:

21

Domain Services for Windows

Author Info

2 July 2007 - 12:18pm
Submitted by: jjaimon

Tags

Novell just released Open Enterprise Server Beta3. It included the first beta of Domain Services for Windows, the much talked about feature from Open Enterprise Server2. Domain Services for Windows received a lot of attention ever since it was demonstrated in the Brainshare this year.

Domain Services for Windows provides the ability to access both Novell Linux and Microsoft Windows services while leveraging the user store without multiple logins or object synchronization. Windows users can get away with the Novell client and still access Novell file and print services from Windows workstations seamlessly. In addition, administrator will be able to setup cross forest trusts between the existing Active Directory forest and Domain Services for windows. This will enable the Domain Services for windows users to access services from a pure Active Directory Forest. ( The reverse is not possible now )

With Novell Domain Services, the end user file and print activities will be identical, regardless of whether the user resides in eDirectory or AD, and the operating system that the file and print services reside on. This will help the user administrator to use the same tools to administer users and groups, irrespective of where the user resides.

The desired user experience for each of the roles is given below:

End Users can use the same default client operations from Windows XP or from Windows 2003 for mapping file system resources and getting access to print services.

  • Help Desk Agent will have the ability to use Microsoft Management Consoles to fully administer users and groups located in eDirectory or AD. Administrators can also use iManager or any legacy eDirectory tool to add users and groups.

Note: Windows administrators will not be able to use iManager or legacy tools to manage Microsoft specific attributes, policies, etc. They must use MMC for this.

  • Directory Administrator will have the ability to use the default vendor tool to administer shares, printers, policies and servers (MMC for AD repositories and group policies and iManager for eDir policies, printers, etc.)
  • Network Administrator will have the ability to install and configure using YaST for Linux and Default Windows install and configure tools for AD.

Use Cases

A typical heterogeneous network may look like the following diagram.

Aquila-approach2

The above deployment diagram has a real AD forest ( msforest.abc.com) and a forest configured with Domain Services for Windows. A replica ring of a configured domain can have Domain Services for Windows servers and supported eDirectory servers - eDirectory 8.8.x and 8.7.3. Administrators can manage the domain using iManger connected to any of these servers while, MMC connects to one of the Domain Services for Windows server. The same set of users can access resources from an Active Directory forest using the cross forest trust – a two way Kerberos based transitive trust between an Active Directory forest and Domain Services for Windows forest





User Comments

Eric's picture

Sounds very cool! Beta3

Submitted by Eric (not verified) on 2 July 2007 - 12:58pm.

Sounds very cool!

Beta3 must not be the public beta that so many people are waiting for?

Also, regarding the statement "This will enable the Domain Services for windows users to access services from a pure Active Directory Forest. ( The reverse is not possible now )". Is this the way the final release will be? If so, any explanation as to why? Just curious.

Mike Faris's picture

I love the fact that I will

Submitted by Mike Faris (not verified) on 3 July 2007 - 4:59am.

I love the fact that I will be able to use SUSE to be my Domain Controllers, but how will this tie in with Identity Manager 3.5?

Ian's picture

Thanks for the update. A

Submitted by Ian (not verified) on 3 July 2007 - 5:03am.

Thanks for the update. A question though, what's the schedule for the open beta, assuming there will be one?

Jaimon Jose's picture

It will not be possible even

Submitted by Jaimon Jose (not verified) on 3 July 2007 - 6:51am.

It will not be possible even by FCS. Its to do with the way authorization data is handled in eDirectory where the data is tightly coupled with the identity itself.

Jaimon Jose's picture

There will be a public beta.

Submitted by Jaimon Jose (not verified) on 3 July 2007 - 6:52am.

There will be a public beta. It might take couple of months more for a public beta.

sysadmin1138's picture

Very sorry to hear that. I

Submitted by sysadmin1138 (not verified) on 3 July 2007 - 8:27am.

Very sorry to hear that. I had some plans for OES2 this summer before school started up again, and without code to test with I simply won't be able to do anything with it. We have some virtualization things going in this summer that I was really hoping to use OES2/Xen paravirtualization to get NetWare in VM. Unfortunately, with this push I'll HAVE to use ESX server. I'm not happy about that, but it is a reality I have to face.

Eric's picture

Ok, so, it's not possible

Submitted by Eric (not verified) on 3 July 2007 - 9:38am.

Ok, so, it's not possible with FCS. How about, is it possible ever (i.e. OES2sp1, OES3). If so, should enhancement req be made or is it already planned for?

Thank you for your reply.

Ian's picture

Unfortunately, yes. I was

Submitted by Ian (not verified) on 3 July 2007 - 11:25am.

Unfortunately, yes. I was hoping for a summer release. With a beta release still months away, the full release has to be three or four months out at least.

Jaimon Jose's picture

IDM is a meta directory

Submitted by Jaimon Jose (not verified) on 3 July 2007 - 7:10pm.

IDM is a meta directory solution and required if you need the same set of identities on both AD and eDir. Both IDM and Domain Services for Windows can co-exist.

Rutger's picture

So what is the idea behind

Submitted by Rutger (not verified) on 4 July 2007 - 8:59am.

So what is the idea behind Domain Services for Windows? Is this the first step Novell customers can take to migrate to a pure Windows network? Is the next step Microsoft buying Novell and SUSE? After a while customers might wonder why there are still a bunch of Linux servers emulating Windows in their network. Face it, Windows CAL needs to be bought anyway as soon as you do something with MS AD. Why buy extra licenses for SUSE servers?

Sebastiaan Veld's picture

Look the other way around:

Submitted by Sebastiaan Veld (not verified) on 5 July 2007 - 1:28am.

Look the other way around: There a lot of company's out there only/mostly using MS products, this can be a first step into Linux for them without too much hassle. So, one can benefit the OES services on Linux, by administrating just one's AD on Windows.

Jaimon Jose's picture

In a different use case, you

Submitted by Jaimon Jose (not verified) on 5 July 2007 - 3:21am.

In a different use case, you can have your existing AD and new or existing SLES with eDir and users can continue to use Windows workstations without learning any new protocols or tools.

Tom Simpson's picture

So how will this affect NMAS

Submitted by Tom Simpson (not verified) on 5 July 2007 - 1:14pm.

So how will this affect NMAS and smart card authentication? We are currently using it on Netware 6.5 and were thinking about getting it all working on Suse Linux. Now we are being told we may have to start drinking the blue coolaid. Would the NMAS methods still work with Domain Services for Suse? Or do we need to move everything on over to MS and be done with it?

Dave's picture

Will Beta 3 be added to the

Submitted by Dave (not verified) on 6 July 2007 - 1:43pm.

Will Beta 3 be added to the Tech Subscriptions download like Beta 2 was?

Sebastiaan Veld's picture

Nobody says you 'have to'

Submitted by Sebastiaan Veld (not verified) on 7 July 2007 - 3:24am.

Nobody says you 'have to' use Domain Services for Windows (DSFW). It just ONE of the Services that comes with OES2 and might be usefull in some cases, for example for customers that have an existing Windows domain infrastructure and that want to use OES2 (services) in that environment. In that sprecific case one could leverage DSFW.

Adding OES2 to YOUR existing environment (NetWare 6.5 with eDir etc) does not change anything for you as an administrator (other then that it runs on Linux) or your users (the way they use the OES services). So in your case you can still use NMAS and token authentication since the NMAS framework is still there.

Andrew's picture

Does this mean you are now

Submitted by Andrew (not verified) on 7 July 2007 - 8:14am.

Does this mean you are now looking at the end of 2007 to release OES2 ( including Netware 6.5 SP7 ) ? If so I will have to adjust some of our plans accordingly.

"End Users can use the same default client operations from Windows XP or from Windows 2003"

Err what, no Vista on the list ?

Jeff May's picture

I just don't see how making

Submitted by Jeff May (not verified) on 5 August 2007 - 2:34pm.

I just don't see how making things easy for Microsoft to extend their dominance is a good thing for anyone but Microsoft.

sk's picture

What domain functional level

Submitted by sk (not verified) on 12 February 2008 - 7:01am.

What domain functional level will this service reflect? win2000, 2003, r2?

Jaimon Jose's picture

Win2003

Submitted by Jaimon Jose (not verified) on 12 February 2008 - 9:06pm.

Win2003

Charlie's picture

As far as I understand it

Submitted by Charlie (not verified) on 7 April 2008 - 7:53am.

As far as I understand it any more useful/advanced aspects of AD and true Windows Domain functionality require physical userids in AD. IDM acheives this nicely.
We are already considering our rollout strategy for Vista by utilising the
Windows Auto Install Kit integrated with System Center Config Manager
(formally SMS) and Group Policy Objects. Considering this is a new system
from Microsoft (to aid Vista deployment and is bound to have issues that all
new systems have!) it will be interesting to see how OES2 Domain Services
for Windows would integrate with this (and Exchange) and keep our lives
simple.

wilsonandrews's picture

Windows Domain Services

Submitted by wilsonandrews on 3 December 2009 - 3:09am.

there is a service named "Netlogon" placed at services is responsible for domain logins.

© 2013 Novell