{"action":"opened","issue":{"url":"https://api.github.com/repos/sqlcollaborative/dbatools/issues/936","repository_url":"https://api.github.com/repos/sqlcollaborative/dbatools","labels_url":"https://api.github.com/repos/sqlcollaborative/dbatools/issues/936/labels{/name}","comments_url":"https://api.github.com/repos/sqlcollaborative/dbatools/issues/936/comments","events_url":"https://api.github.com/repos/sqlcollaborative/dbatools/issues/936/events","html_url":"https://github.com/sqlcollaborative/dbatools/issues/936","id":213291643,"number":936,"title":"Test-DbaSpn and Get-DbaSpn, minor bug in domain restrictions","user":{"login":"niphlod","id":122119,"avatar_url":"https://avatars1.githubusercontent.com/u/122119?v=3","gravatar_id":"","url":"https://api.github.com/users/niphlod","html_url":"https://github.com/niphlod","followers_url":"https://api.github.com/users/niphlod/followers","following_url":"https://api.github.com/users/niphlod/following{/other_user}","gists_url":"https://api.github.com/users/niphlod/gists{/gist_id}","starred_url":"https://api.github.com/users/niphlod/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/niphlod/subscriptions","organizations_url":"https://api.github.com/users/niphlod/orgs","repos_url":"https://api.github.com/users/niphlod/repos","events_url":"https://api.github.com/users/niphlod/events{/privacy}","received_events_url":"https://api.github.com/users/niphlod/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2017-03-10T09:43:08Z","updated_at":"2017-03-10T09:43:08Z","closed_at":null,"body":"### bug\r\n\r\nWhen checking the existence of the account all of \"SPN\" commandlets strip the domain part from the account, assuming the account is registered under the same domain of the server running MSSQL.\r\nIt *can* happen (and if something strange happens, niphlod has it) that you have a domain forest like so\r\n- corp.com\r\n- subcorp.corp.com\r\n\r\nwhen the server is registered under subcorp.corp.com, but the user is on corp.com, the root DN for the search is not taken into account.\r\n\r\nGet-DbaSPN shows the correct account (i.e. corp\\mssql_user) ... Test-DbaSPN too .... but then when you pipe it down to Set-DbaSPN it gets stripped. (yeah, I know there is a \"domain\" parameter, but the wording in this case is misleading)\r\n\r\nA little more serious, what happens with Test-DbaSpn is that the SPN is reported to not being there ... but it's because the object is not found on subcorp.corp.com rather than because the SPN is missing at all.\r\n\r\n```.PARAMETER Domain\r\nIf your server resides on a different domain than what your current session is authenticated against, you can specify a domain here. This\r\nparameter is optional.\r\n```\r\nit should instead be\r\n```.PARAMETER Domain\r\nIf your server OR THE SERVICE ACCOUNT resides on a different domain than what your current session is authenticated against, you can specify a domain here. This\r\nparameter is optional.\r\n```\r\n\r\n\r\n\r\nThat being said (i.e. that technically documenting the shortcoming in this particular corner-case is fine) the cmdlet *could* use [System.DirectoryServices.ActiveDirectory.Forest]::GetCurrentForest() to search properly the accounts in all of dbatool's spn commandlets (i.e. \"retaining the info\" about the domain where the account is reported to be and searching in the correct DN)\r\n\r\n\r\n"}}
{"actor":{"display_login":"niphlod"}}