Is it possible to define AD DS domain/forest functional levels from domain joined workstation? Preferably through CLI/PS and if possible w/o Domain Admin rights... How I can accomplish it?
Asked
Active
Viewed 2.9k times
5 Answers
11
The following Powershell does not require admin or domain admin access, I've tested as a limited user on a domain-joined workstation with Powershell v2/v3. It does not require any third party tools or Powershell modules.
$dse = ([ADSI] "LDAP://RootDSE")
# Domain Controller Functional Level
$dse.domainControllerFunctionality
# Domain Functional Level
$dse.domainFunctionality
# Forest Functional Level
$dse.forestFunctionality
The values returned will represent a distinct functional level:
Value Forest Domain Domain Controller
0 2000 2000 Mixed/Native 2000
1 2003 Interim 2003 Interim N/A
2 2003 2003 2003
3 2008 2008 2008
4 2008 R2 2008 R2 2008 R2
5 2012 2012 2012
6 2012 R2 2012 R2 2012 R2
7 2016 2016 2016
References:
jscott
- 24,484
- 8
- 79
- 100
3
Just a complementary solution to the accepted answer, as I ended up here more or less with the same need. The difference is one gets the level name decoded:
Import-Module ActiveDirectory
$ForestRoot = 'top.domain'
(get-adforest -identity $ForestRoot).ForestMode
(get-adforest -identity $ForestRoot).Domains |
ForEach-Object {Get-ADDomain -Identity $_ |
ft DNSRoot,DomainMode -AutoSize}
ErikE
- 4,746
- 1
- 20
- 27
-
1+1. Worth noting yours requires the Microsoft Powershell AD Module. The ADSI example does not. – jscott Jun 10 '15 at 11:08
-
Right you are, editing it in.. – ErikE Jun 10 '15 at 11:09
-
Minor improvement. You don't actually need to include the `-identity $ForestRoot` portions of the get-adforest commands when you're running it from a machine joined to the forest you're trying to query. The cmdlet will just pick up the current machine's info. – Ryan Bolger Jun 15 '16 at 19:21
2
You just want to check it or actually change it? Changing it would require certain administrative rights on the domain/forest.
The easiest way I can think of without dsquery or PS Get-ADDomain (which would require importing the AD module) is to use Joeware's ADFIND command.
http://www.joeware.net/freetools/tools/adfind/
adfind -rootdse domaincontrollerfunctionality domainfunctionality forestfunctionality
Example output from my domain:
AdFind V01.47.00cpp Joe Richards (joe@joeware.net) October 2012
Using server: DOMAIN-DC1.hahaha.local:389
Directory: Windows Server 2008 R2
dn:
domainFunctionality: 4 [Windows Server 2008 R2 Domain Mode]
forestFunctionality: 4 [Windows Server 2008 R2 Forest Mode]
domainControllerFunctionality: 4 [Windows Server 2008 R2 Mode]
1 Objects returned
TheCleaner
- 32,627
- 26
- 132
- 191
1
For a GUI-based approach you can use Active Directory Explorer. Right-click on domain top node, click Properties and check the value of domainControllerFunctionality, domainFunctionality or forestFunctionality. They have integer values corresponding to:
0 = Win 2000
1 = Win 2003 mixed/interim
2 = Win 2003
3 = Win 2008
4 = Win 2008 R2
5 = Win 2012
6 = Win 2012 R2
7 = Win 2016
bogdan
- 65
- 11
0
You need to ask this question a little differently, because I'm not sure what you are trying to do- The way this reads is that you want a powershell script or batch file that can perform extremely administrative tasks without running as a user that is able to perform those tasks. If that's what you are asking, it's not possible, by design.
However, if you are asking about administering AD from a workstation, by handing a user a script that can run commands the user otherwise would not be able to (i.e. you want to query AD from an unprivileged service account), we would need to know what version of Powershell you are using, and what version of Server you are using.
You might also consider AD web services for one-at-a-time tasks that you wish to delegate.
From a TechNet post: Run The below DSQUERY
Dsquery * CN=Partitions,CN=Configuration,DC=Mydomain,DC=com -scope base -attr msDS-Behavior-Version
Output: msDS-Behavior-Version 2
The attributes that indicates DFL and FFL: - Forest level setting
Name: msDS-Behavior-Version Path: CN=Partitions, CN=Configuration, DC=, DC=com
Value: 0 or not set=mixed level forest
1=Windows Server 2003 interim forest level 2=Windows Server 2003 forest level 3=Windows Server 2008 forest level
- Domain level setting
Name: msDS-Behavior-Version Path: DC=, DC=, DC=com (domain root) Value: 0 or not set=mixed level domain
1=Windows Server 2003 domain level 2=Windows Server 2003 domain level 3=Windows Server 2008 domain level
- Mixed/Native mode setting
Name: ntMixedDomain
Path: DC=, DC=, DC=com (domain root)
Value: 0=Native level domain 1=Mixed level domain
I'm not sure about the role requirements of the user to run this, but you're not changing anything with it and it's all using DSQUERY (From the RSAT, free download from Microsoft). Comment if we need to look at that end of it.
user1467163
- 63
- 8
-
My question was for a situation when let's say member of IT department who not a domain admin needs quickly verify/double check domain/forest functional levels w/o bothering domain admins who should know than & have all appropriate consoles & tools to check it... Any quick & simply method would do for me – Mikhail May 31 '13 at 13:42
-
1I get that this question is an exercise in "how can this be done", but nevertheless I can't think of a single scenario where an IT team member who doesn't have the appropriate rights would need to do this in the course of their job. – joeqwerty May 31 '13 at 14:02
-
I worked at a large firm, and this kind of information would be useful at such a company. Here's an example: your location has a domain with aging DC's and you need to implement a feature of a newer FL to fulfill a ticket request. You may not be chummy with the already overburdened domain admin. To make the case for needed upgrades, you have to put together the process, which is purely research so you can get the change request together- this is an ITIL requirement. This would be very useful in such a situation. – user1467163 May 31 '13 at 14:30