So I have shown how to setup/install NAV 6 before, but I am playing around with 2013 and had a few issues. First of all, the .TCP sharing services trick didn’t seem to want to work for me (I have seen blog post from others showing it does work but it is not all that important for me right now) so first thing we need to do is find a free port (4 actually)
$properties = [System.Net.NetworkInformation.IPGlobalProperties]::GetIPGlobalProperties()
$TcpConnections = $properties.GetActiveTcpConnections()
$clientport = 0; $mgtport = 0; $odataport = 0; $soapport = 0; $freeport = 0;
for ($freeport=6000;$freeport -le 7000; $freeport++){
if( ($TcpConnections | Where-Object {$_.LocalEndPoint.Port -eq $freeport}).count -eq 0){
if($clientport -eq 0){ $clientport = $freeport }
elseif($mgtport -eq 0){ $mgtport = $freeport }
elseif($odataport -eq 0){ $odataport = $freeport }
elseif($soapport -eq 0){ $soapport = $freeport }
else { break }
}
}
write-host "Create NAV Service '$InstanceName' using clientport: $clientport mgtport: $mgtport odataport: $odataport soapport: $soapport"
Right, next thing is installing the service. I really don’t like running stuff as local system, so lets use a windows user.
Add-PSSnapin "Microsoft.Dynamics.Nav.Management"
$Password = ConvertTo-SecureString $NAVAdminPassword -AsPlainText -Force
$cred = new-object -typename System.Management.Automation.PSCredential -argumentlist $NAVAdminUPN, $password
New-NAVServerInstance -ServerInstance $InstanceName -ClientServicesPort $clientport -ManagementServicesPort $mgtport -ODataServicesPort $odataport -SOAPServicesPort $soapport -ServiceAccountCredential $cred -ServiceAccount User
Once the service starts, you will start getting an warning in the event log “
The service account has insufficient privileges to register service principal names in Active Directory.
And that is even if you registered the SPNS manually. So to shut it up, and just give it the permissions to do that:
$ADNAVAdminUser = Get-ADUser $NAVAdmin.Username
$self = New-Object System.Security.Principal.SecurityIdentifier([Security.Principal.WellKnownSidType]"SelfSid", $ADNAVAdminUser.Sid.tostring())
$rule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule($self, [System.DirectoryServices.ActiveDirectoryRights]::WriteProperty, [System.Security.AccessControl.AccessControlType]"Allow")
$dn = $ADNAVAdminUser.DistinguishedName
$U = [ADSI]"LDAP://$dn"
$Result = $U.ObjectSecurity.AddAccessRule($rule)
$U.CommitChanges()
Hi,
SvarSlethow is it possible to give the service account the right to register service principal names in AD without Powershell, i.e. with the normal AD account GUI?
Thanks,
Thorsten
At first I was all "sure" no problem. But couldn't really find it. Please note, in above powershell, im just giving write, and you can do that. But if you wanner do it paranoidly, you only wanner grant read and write permission to the "servicePrincipalName" property.
SletSeveral guides show how to do that on an computer account (for instance http://www.ctc-g.co.jp/~ctcsp/products/doubletake/availability_user's%20Guide/Content/AppMgrImport/CredentialsSPNUpdate.htm ) but that options seems to be missing on User Accounts. It's also not present on OU/Container level, so cant just inherit the permission "down ward". Abit wierd, considering "msDS-AllowedToDelegateTo" is there on all levels.
So i guess the sad answer is no, your "stuck" with granting Write Permissions more widely.
( Advanced -> Add -> Self -> Ok -> "Write all Properties" )
Denne kommentar er fjernet af forfatteren.
SvarSlet