We have an issue where our Test and QA and Production environments do not appear to be enumerating through the active directory groups list when the group is added to a SharePoint group (we are controlling SP access using AD groups). These are not nested groups. Have you any idea what could be causing this? What is really confusing is that it is adding some, but not all. For instance, we found 4 people who were missed in the initial group setup. So this afternoon we added them into the AD group. Of those 4 people, SharePoint can see 2 and can't see the other 2. There is no properties that we can see that are different between the working and non working accounts. 2 accounts sit in the same OU and have the same group access, but SharePoint only resolves one of the accounts and can't see the other. If it wasn't seeing any of them I would put it up to a refresh job that hadn't run yet or a sync between AD and SP, but that can't be the case here because SP is resolving some of the accounts.
We do have accounts sitting in different OUs being added to the AD Group, but this is affecting accounts that share the same OU as well.
I would appreciate any insight anyone would have.
One last thing I should mention, though I don't know if it is an issue or not, we are running Active Directory 2003.
Thank you
Try changing the token cache timeout, we had similar issues and the command bellow (source) + IIS reset solved it:
stsadm -o setproperty -propertyname token-timeout -propertyvalue 1
Related
Recently, something has change with the Azure resources view in the VS Code extension.
I have 3 accounts I typically sign in with:
Personal
My Company
My customer
As recently as the April timeframe, I was able to use the extension to deploy logic apps into my customer's Azure tenant. Now whenever I sign in to them, I see nothing in the extension, in fact it behaves as if I've not signed in at all. But my other two accounts work as expected.
No Resources in customer account
My Company account with resources
I have signed in/out multiple times. I have uninstalled/reinstalled the extension(s). This is happening on both my Windows 11 and Mac machines.
I'm down to beleiving that this may be some corporate restriction/policy implemented by my customer's IT, as they are trying to reorganize and restructure their Azure environments. And yes, I still have access overall, because I can log into the portal see the resources just fine.
Would anyone know of such a setting, and what it might be? Or know anything else to try?
Despite wrestling with this for over an hour yesterday, it appears to have resolved itself, or my one last try of starting with a rebooted machine, signing in to the portal first, THEN signing in with the extension seems to have got it back up and running....
I was able to sign out of Azure in VS Code using this:
https://stackoverflow.com/a/53707442/79558
Then I signed into portal.azure.com, then signed back into VS Code.
I'm wondering if it had something to do with my org requiring multi factor authn more often for access to portal.azure.com.
I have a user that is getting alerts from TFS. When I looked at [Tfs_Configuration].[dbo].[tbl_Identity] I found several people that I have no idea how they got in there.
When I do a backup of the TFS server through the console, they get an email notification.
How do I remove them? I have tried attempting to sync with JobService, rebooted the server, looked in AD at the person, and I've looked in TFS in User Management in the Console. They are not there. I can find them in TFS if I search for a Subscriber on a Project, but nothing in regards to backup or the like or a way to remove them from the entire TFS instance.
I have also looked a the Console and group membership for individual projects. They are not Team Foundation Administrators.
You do not: TFS/VSTS/ADO needs to refer to past users reference in work item, version control and other subsystems.
You can break your database in an unrecoverable way modifying the tbl_Identity table.
The only reasonable thing to do is to remove these users from all TFS (and Active Directory) groups so they only appears in old data. The TFSSecurity utility can help you identify which groups has a specific user.
I have two additional AD I have created in addition to the one which is associated to the subscription. I want to delete those but my attempt fails with the message "Directory has one or more applications that were added by a user or administrator"
I can see below two common application in both directories, where I don't see a delete button.
Office 365 management apis
Visual Studio Team Services
How can I delete this AD?
Thanks,
Shiju
I ran into the same issue. The only solution I was able to find was to step into PowerShell and get it done. You can find the steps in these two posts:
https://social.msdn.microsoft.com/Forums/en-US/afbfb7b3-92c9-4af6-9128-ba96795de5a6/not-able-to-delete-b2c-tenant
https://social.msdn.microsoft.com/Forums/en-US/e041555c-aa36-4369-bbb9-1f23ae317304/how-to-remove-active-directory-from-windows-azure
The main gist is that you need to have a global admin account which is a direct member of the directory. You can't use your Microsoft/subscription account even though it may have been granted global admin permissions. You then connect using these credentials in PowerShell, find the Service Principals (aka Applications) which exist, and remove them. You can then drop the Admin account for the directory and delete the directory itself.
I also wrote a blog page on how to delete an active directory tenant. I have updated the process to use the new portal and the newer AzureAD PowerShell cmdlets.
https://blog.nicholasrogoff.com/2017/01/20/how-to-delete-an-azure-active-directory-add-tenant/
We have both internal and external users on Windows SharePoint Services 3.0. We are using Windows Integrated authentication and have all users, both internal and external, in the same domain. We are allowing all users access to the application by adding the Domain Users group. The issue is that there are certain sites that need to be secure from the external users, but because they are in the same domain they have access. We have removed the Domain Users group from some sites and then explicitly assigned permissions to a dedicated group in Active Directory, but we have around 100 sites that we need to do this for and it would become an administrative nightmare to do this for all 100 sites.
I've done some searching and it looks like we might be able to accomplish this using zones, but when we tried last week we broke the entire application. Does anyone have any ideas?
The other option is to move the WSS server into a different domain and give the external users accounts in that domain so that we could keep them separate, but I wanted to see if there was a better way to do this.
Work on creating automation that creates and maintains Active Directory security groups that contain lists of internal or external users. Surely there is an attribute or two that distinguishes between these different types of users.
While you are at it, update your user provisioning process to make sure that when you create accounts, they get stuck in one group or another.
It would seem to be relatively simple to automate the process of changing your security using a powershell script?
An example of a script like that is here
The userid that is the identity of the application pool is also in the Farm Administrators group.
Is that a bad thing?
We started seeing some weird permission errors after this change was made (that userid was added to the farm admin group).
Microsoft recommends using seperate accounts:
http://technet.microsoft.com/en-us/library/cc263445.aspx#Subsection2
We have done this several times in our dev environments where we wanted one single account with godlike permissions on everything.
It should not be causing permission problems as far as I know, but SharePoint can be a bit...fickle in this regard.