The problem is as follows:
- I've got users defined on server A (domain controller),
- I've got SharePoint Farm installation on server B (fresh install)
After installation i have started the Profile Synchronization process, so i've got all the required users in sync. After i created a site i've assigned USER1 as its administrator / owner.
As i understand the USER1 user should have access to:
- site settings / permissions
- site content
Unfortunately i stuck with the situation where user can login on his my-domain\USER1 account, and he can access MOST of the pages. The rest:
example.net/ (http://example.net/default.aspx IS accessible)
example.net/test/ (http://example.net/test/SitePages/Home.aspx IS accessible)
example.net/test/SitePages/
causes re-authentication.
It is really easy to solve by adding users / group defined in PDC to local WSS_WPG group, but i don;t think this is the solution.
I will really appreciate your help !
The problem was in AD configuration.
Domain Users must have Bypass Traverse Checking enabled to avoid that issue.
For more information you can check following links:
http://technet.microsoft.com/en-us/library/cc787794%28v=ws.10%29.aspx
http://technet.microsoft.com/en-us/library/cc739389%28v=ws.10%29.aspx
www.windowsitpro.com/article/performance/how-to-use-the-bypass-traverse-checking-user-right
Related
I have a scenario where MDS admin users and MDS application pool exist in domain A , normal MDS users exist in domain B.
While this scenario worked with MDS 2012 after upgrade to MDS 2016 I am not able to navigate to functional area in MDS user security management with A\admin user- it yields "Access is Denied". Other areas in user security management work. The only information I could find in MDS log is: The user name or password is incorrect.
I thought it might be related to fact that cross forest domain roaming is disabled and those B domain users cannot have fully imported profiles on MDS machine. I have enabled it, forced GPO refresh - doesn't work
I tried with MDS database and application created by user from domain B - doesn't work
Any ideas how to investigate or fix it?
It looks like workaround is to create local user group for MDS users and then add this group to MDS.
This way you can change all permissions for a group. Each domain user will get created with all settings inherited from group.
SonarQube v5.2
I am trying to create a technical user (one that is authenticated locally and not against our LDAP). I have added a user name to the conf/sonar.properties file and restarted SonarQube. But, when I log in (as an administrator), the new user doesn't show up in the Administration | Security | Users list. We have two previously defined technical users (including admin) which do show up.
The admin guide doesn't say much http://docs.sonarqube.org/display/SONARQUBE52/Authentication.
Is there another step needed to create a technical user?
You need to manually create the user in SonarQube, it won't be automatically at startup.
Note that the SonarQube version you're using is no more supported, you should migrate to the latest LTS version 5.6.X => local users (previously known as technical users) are better managed :
- No more need to update sonar.properties
- You just have to create a user from the web server, this user will automatically be considered as a local user.
I've updated http://docs.sonarqube.org/display/SONAR/Authentication in order to remove the "Technical" word.
I have a simple VB.net console application that displays the current user, waits for key input, and then exits. It uses the following call to display the information:
System.Security.Principal.WindowsIdentity.GetCurrent.Name.ToString()
If I create a remote app hosting this application, and create an azure user that has rights to run the remote app such as;
thisisa#test.onmicrosoft.com
When this user connects to the remote app the output of the line of code above would look something like;
YLSDAAYU0007\thisisa_000
Is there anyway of reading the user running the remoteapp at the time? in this case, I am looking to obtain thisisa#test.onmicrosoft.com ?
Catalin from the RemoteApp team here. You have stumbled across one of our implementation details here :)
Windows does not allow automatic login with Azure Active Directory (AAD) users: they only allow users that have Microsoft Accounts or domain accounts in case the collection is domain joined. We are working around this limitation by creating a local user on the VM and logging in with that user instead of the AAD user.
If you have any more questions about this, feel free to contact me: catalda ＠ microsoft com
I setup a little server and have it authenticating with ldap.. is there a way to restrict which ldap user can login via ssh without adding an account to the opensuse box?
1 - Create a group on LDAP using YaST's User and Group Management, for instance "serveradmins".
This will create a entry on your LDAP server under the group OU.
2 - Add the allowed users to this group, also using YaST
3 - On the servers you want to restrict the access, edit the /etc/ldap.conf, making sure the following instructions are present (uncommented), mind changing the DC= parts to your configuration:
pam_groupdn cn=serveradmins,ou=group,dc=example,dc=com
pam_member_attribute member
Let me know if this worked well for you. I have this working on OpenSUSE and Ubuntu machines.
I am currently setting up a dev environment which is an exact copy of our prod environment. The problem is when I try to authenticate a user by using CFLDAP tag in the dev environment, it won't let me authenticate the user without prefixing the username with the domain name while in the prod environment we don't have to prefix the username with the domain name. See example code below:
Details:
Windows 2000 Web Server
ColdFusion 5
Authenticating to a Windows 2003 Active Directory environment
Any help is greatly appreciated.
I have found when using CFLDAP, that using NT style logins for the username will inevitably cause problems and inconsistencies. You are really much better off using the distinguishedName attribute (DN) for a given user:
CN=User,OU=Users,DC=domain,DC=com
Of course your DN will likely be different - but hopefully that illustrates the point.