TFSSecurity with vstfs:///Classifcation IDs - powershell

I'm trying to script some permission removals from a user list using PowerShell. The problem is that when I perform a command to list the user groups associated with the user, I get a generic result that cannot be used when I perform the command to remove the user from that group.
To get the groups for the user:
tfssecurity /im <domain>\<username> /server:<tfsserver>:8080/tfs
Results:
The target Team Foundation Server is
http://:8080/tfs/. Resolving identity
"\username"...
SID: S-1-5-21-3609080306-XXXXXXXXXX-XXXXXXXXX-5728
DN: CN=LastName, FirstName,OU=Disabled Users,DC=company,DC=com
Identity type: Windows user Logon name: \ Mail
address: username#domain.com Display name: lastname, firstname
Description: TFS User
Member of 1 group(s): [A] [TeamProject]\Developers
Done.
The Problem: When I try to remove the user from the group returned:
tfssecurity /g- "[TeamProject]\Developers" <domain>\<username> /collection:http://tfsserver:8080/tfs/collection/
I get:
The target Team Foundation Server is
http://tfsserver:8080/tfs/collection. Resolving identity
"[TeamProject]\Developers"...
Error: The identity cannot be resolved.
What I'm looking for, is something like:
vstfs:///Classification/TeamProject/af89c143-2f5e-4f5b-974e-903e8db86f73\Developers
I do know that the TFS UI can provide those group SIDS, but I'd like to see if I can get those SIDS from TFSSecurity or other command base to that can be leveraged by PowerShell.
C:\Program Files (x86)\Microsoft Visual Studio 14.0>tfssecurity /g-
"[Archive Projects]\Developers" \
/server:http://:8080/tfs/ Microsoft (R) TFSSecurity - Team
Foundation Server Security Tool Copyright (c) Microsoft Corporation.
All rights reserved.
The target Team Foundation Server is
http://tfs-na.ihs.com:8080/tfs. Resolving identity
"[Archive Projects]\Developers"...
Error: Multiple identities found matching '[Archive
Projects]\Developers'. Please specify one of the following identities:
[Archive Projects]\Developers (vstfs:///Classification/TeamProject/8153b33c-addc-48c2-81c0-XxXXXxxxXXXX\Developers)
[Archive Projects]\Developers (vstfs:///Classification/TeamProject/f3d25cfe-41b3-4f30-a329-BBBbbBBBbbbb\Developers)
[Archive Projects]\Developers (vstfs:///Classification/TeamProject/c0820b8e-2af0-416c-88b5-CCcccCCCccCC\Developers)

No need to use SID in the using of tfssecurity /g- command. Your command is right.
tfssecurity /g- "[TeamProject]\Developers" <domain>\<username> /collection:http://tfsserver:8080/tfs/collection/
According to the error The identity cannot be resolved, this is more like a connectivity problem with the domain server. Use a direct connection between the Team Foundation Server en de AD server, all identities can be resolved. Besides, if you are using two different domains with your account and TFS server. Make sure they are trusted each other, details take a look at this question: TFSSecurity Unable to Resolve Identity

Related

gcloud identity groups memberships list command not working in github actions

I am trying to list members of google group with follow command, however same command is working when run from cloud sdk on my local machine
C:\Program Files (x86)\Google\Cloud SDK>gcloud --project=projectID identity groups memberships list --group-email="groupemail"
When above command is ran from github actions, it throws following error
ERROR: (gcloud.identity.groups.memberships.list) Invalid value for [--group-email]: There is no such a group associated with the specified argument:'groupemail mentioned in command'
Need suggestion on this behavior.
I am trying to list members of google group with follow command, however same command is working when run from cloud sdk on my local machine
C:\Program Files (x86)\Google\Cloud SDK>gcloud --project=projectID identity groups memberships list --group-email="groupemail"
When above command is ran from github actions, it throws following error
ERROR: (gcloud.identity.groups.memberships.list) Invalid value for [--group-email]: There is no such a group associated with the specified argument:'groupemail mentioned in command'
Need suggestion on this behavior.

What does 'System.ConfigItem.ObjectStatusEnum.Active' represent in SCOM

I query the following SCOM endpoint: OperationsManager/data/objectInformation/<object id>
Among the response properties, I receive the following property:
<MonitoringObjectProperty>
<name>Object Status</name>
<value>System.ConfigItem.ObjectStatusEnum.Active</value>
</MonitoringObjectProperty>
I want to know what this property represents. I am looking for a way to query the API to figure out if a given server is running or not (crashed/network disconnected etc) & wondering if this property represents this attribute.
It is not used in SCOM, its leftover from System Center Service Manager. Back in 2012 when they built Service Manager SCSM they used the code base from SCOM 2012. Then they merged the updated code SCSM back into SCOM (for some unknown reason) this created a bunch of useless properties and tables in the SCOM DB.
Many of these fields can still be updated manually with PowerShell but I would not recommend it.
Here is a link for more information. Using the Asset Status Property in SCOM
Here is how you can use the API to get server status. SCOM REST API to get Windows/Linux machine's availability (whether the server is running & reachable)?

Is it possibe to have multiple kerberos tickets on same machine?

I have a use case where I need to connect to 2 different DBS using 2 different accounts. And I am using Kerberos for authentication.
Is it possible to create multiple Kerberos tickets on same machine?
kinit account1#DOMAIN.COM (first ticket)
kinit account2#DOMAIN.COM (second ticket)
Whenever I do klist, I only see most recent ticket created. It doesn't show all the tickets.
Next, I have a job that needs to first use ticket for account1 (for connection to DB1) and then use ticket for account2 (for DB2).
Is that possible? How do I tell in DB connection what ticket to use?
I'm assuming MIT Kerberos and linking to those docs.
Try klist -A to show all tickets in the ticket cache. If there is only one try switching your ccache type to DIR as described here:
DIR points to the storage location of the collection of the credential caches in FILE: format. It is most useful when dealing with multiple Kerberos realms and KDCs. For release 1.10 the directory must already exist. In post-1.10 releases the requirement is for parent directory to exist and the current process must have permissions to create the directory if it does not exist. See Collections of caches for details. New in release 1.10. The following residual forms are supported:
DIR:dirname
DIR::dirpath/filename - a single cache within the directory
Switching to a ccache of the latter type causes it to become the primary for the directory.
You do this by specifying the default ccache name as DIR:/path/to/cache on one of the ways described here.
The default credential cache name is determined by the following, in descending order of priority:
The KRB5CCNAME environment variable. For example, KRB5CCNAME=DIR:/mydir/.
The default_ccache_name profile variable in [libdefaults].
The hardcoded default, DEFCCNAME.

InternalServiceFault when trying to connect SPGo to SP Online in VS Code

I'm trying to connect the SPGo plugin in Visual Studio Code to a Sharepoint Online site. There are lots of guides for this, for instance this one: https://medium.com/niftit-sharepoint-blog/saying-goodbye-to-sharepoint-designer-ac939a0b79ba
In short, I'm doing it like this:
Open VS Code
Open a local, empty folder)
SPGO: Configure workspace (follow guide, ending up with spgo.json
looking like the one I pasted)
SPGO: Populate local workspace (asking me for credentials and I plot
it in O365 style (email and password).
Statusbar says "Populating workspace"
After about 10 seconds I get the pasted error in the output window (spgo)
I'm using newest versions:
Visual Studio Code 1.37.1
SPGo 1.4.3
I have tried various sites in my tenant and I know they are up. I am Site Collection Administrator for the sites. I know the credentials are correct, of course. the remoteFolders and publishingScope doesn't affect anything, when changed. I assume authenticationType should be "Digest".
SPGo.json:
{
"sourceDirectory": "src",
"sharePointSiteUrl": "https://domain.sharepoint.com/sites/SiteName",
"publishingScope": "Major",
"authenticationType": "Digest",
"remoteFolders": [
"/SitePages/"
]
}
I don't get any files in the local folder, instead I get an error in the output:
================================ ERROR ================================
<s:Fault>
<s:Code>
<s:Value>s:Receiver</s:Value>
<s:Subcode>
<s:Value xmlns:a="http://schemas.microsoft.com/net/2005/12/windowscommunicationfoundation/dispatcher">a:InternalServiceFault</s:Value>
</s:Subcode>
</s:Code>
<s:Reason>
<s:Text xml:lang="en-US">The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework SDK documentation and inspect the server trace logs.</s:Text>
</s:Reason>
</s:Fault>
Error Detail:
----------------------
{}
===============================================================================
Sorry I missed this post for so long. First- thanks for the detailed write-up. This is the first time I've seen this specific issue with SPGo, so I do not know for sure what is the root cause.
Couple questions:
Are you using ADFS Authentication with your Office 365/SharePoint Online instance?
Are you able to use Addin-Only Authentication on this SP Site?
SPGo should be able to automatically work with ADFS in SharePoint Online but, as a fall-back, you could use Addin-Only Authentication. In this scenario you would create a ClientId and ClientSecret pair for the SharePoint Site Collection you are accessing and authenticate using those credentials. The ClientId would act as your UserName, and the ClientSecret would be your password.
Under the covers, I am using the node-sp-auth package for user authentication. Sergei (s-KaiNet on Github) has a great write-up on how to enable Addin-Only Authentication in SharePoint Online on his site, which you can find here.
Thanks for using SPGo!

Checkout issue from Windows ClearCase client

A user cannot checkout from windows client ClearCase ( see picture)
And yet, the same user can checkout from a unix client.
Why?
Thanks for your answer #VonC
Please find my below findings
Here the primary group of the vob is
/usr/atria/bin/cleartool desc vob:/vobs/MCT
versioned object base "/vobs/MCT"
created 2010-03-03T16:42:52+02:00 by Admin.WTD (wtadmin.wtusers#frmrssucc004)
"MSS Access"
master replica: xh_mct_athens#/vobs/MCT
replica name: xh_mct_athens
VOB family feature level: 5
modification by remote privileged user: allowed
atomic checkin: disabled
VOB ownership:
owner *********servername***/ca_xhvadm
group eelinnis.emea.nsn-net.net/ccusers_xhaul_athens
ACLs enabled: No
Attributes:
FeatureLevel = 5
Hyperlinks:
AdminVOB -> vob:/vobs/MPTADMIN
And user id output is
id karageor
uid=61333334(karageor) gid=8003(ccusers_xhaul_athens)
groups=7000(hostingusers_cic_athens),8003(ccusers_xhaul_athens)
and on the windows the primary group is set as
Is the unix group ccusers_xhaul_athens has to be set as windows primary group on system variable
Kindly confirm
The main factor which explain a permission issue in a ClearCase interop (Windows ClearCase client - Linux ClearCase server) is the CLEARCASE_PRIMARY_GROUP environment variable.
That variable (CLEARCASE_PRIMARY_GROUP) needs to:
be set to the primary group of the vob of the element the user is trying to checkout (primary or secondary: type cleartool describe -l vob:\YourVob to list them)
be the same value as the primary group of the Linux user (who can successfully checkout the same element in his/her Linux ClearCase view): type id -a to see that primary group eelinnis.emea.nsn-net.net/ccusers_xhaul_athens
Make sure on Windows the user is not launching the client with another account (Administrator, or System account), and the CLEARCASE_PRIMARY_GROUP is set.
(and the number of group is not too high)
You can use the creds utility to see your credentials.
See more at "ClearCase won't allow Check-In" and use the credmap utility to verify the group assignments between Windows and Unix.
Type set CL in a CMD shell in Windows to see the actual full value of the CLEARCASE_PRIMAY_GROUP environment variable (??_EE_CLEARCASE_USERS_XHAUL_ATHENS)
You need to see if that group maps to the Linux one.
Check also the protection associated to your view. See fix_prot on Windows here.