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.
Related
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'm just in the process of trying to properly configure asp.net 4.5 on our IIS servers.
I have been able to navigate and launch an ASPX page that contains no data conenctions sucessfully so I know that the application pool authentication to the local directories is working as it should.
Now though I have a seperate SQL server that is connected to the domain and have a connection string stored in the code that connects the ASPX page to the server using a trusted connection. When running in visual studio debug mode, the connection works fine - but at that point I assume it is using my login credentials.
My question is, when a user calls the aspx page via the browser when hosted on the new IIS7 server, which account is used to call the SQL server when using a trusted connection? - Is it the end users or is it a local account from the IIS server?
When I call a page with data connections embedded I get the error: Login failed for user ADMIN\PCNAME$ ... which is an indication that this is the account that it is using. However this account doesn't exist on the domain that I'm aware of. - Or does it ?!
Thanks in advance,
It will use the account that ASP.NET is running under, as you've worked out. What you usually should do is create a Domain Account (with the right privileges) and run your ASP.NET AppPool under that account. Then a Trusted Connection will use that account for connecting to the database, and as long as you've given it access (which as a Domain Account you can do) it should all work.
Added:
After some back and forth on comments, lets go back to the start: set the new AppPool to run with the domain users account, and recycle the AppPoolo. What is it that says the password is wrong? If it's IIS trying to start the AppPool, then it is extremeny likely that the Password you gave the AppPool IS wrong, or else that the password is set to change on first logon.
If its not IIS, but opening a Database connection, are you sure that the database allows this Domain Account access to the database and the tables within it it will need? What roles have you assigned to this account? Also, what SQL statement is it trying to execute (if it's got far enough to try and execute a statement at all)?
I suggest you put any response in you original question - comments get to be a drag if there are too many of them.
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
I am trying to figure out what is going on. Here is our setup:
We have four SQL servers that are in replication with each other.
We add a new user to Windows Active Directory and add them to a group that is in SQL Server that we have been using for ages.
The new user, when trying to authenticate using Windows authenication returns that error in the subject line. But, any users that were previously in Active directory work fine.
At one point I had gotten SQL Server "caught up" becauuse we had a group of users that could not log in because of this error. I did some changes to the SPNs and ended up making it so no one could log in. Then I realized how the SPNs were supposed to look and fixed it. Then I guess some magic happened and those users were able to authenticate. I thought it was fixed, but it is obviously not as we had to add one new user and they cannot authenticate.
What is interesting is that the user can authenticate with three out of the four SQL Servers. It is only this one server that is working incorrectly. I set up two SPNs for the SQl Service on this sql server.
They look like -
MSSQLSvc/[servername].[domain].local:1433
MSSQLSvc/[servername]:1433
These are actually registered to the Service account that we use for the SQL Servers. What is interesting is that I can't find the SPNs for the servers that are working anywhere.
Any help would be appreciated!
Edit: Also, another point to note is that if I try to add the user directly as a login into SQL server. I right click Logins and click Add Login then click search. I then type in [Domain]\[Username] and click check names. It validates the name as being correct. Then I click OK. And then OK again, and it gives the Error Windows NT user or group '[Domain]\[Username]' not found. Check the name Again.
I thought it was fixed, but it is obviously not as we had to add one
new user and they cannot authenticate.
The user has to relogin in order to pick up the new group. Otherwise, it's kerberos ticket is still using the old group membership information in its PAC
These are actually registered to the Service account that we use for
the SQL Servers. What is interesting is that I can't find the SPNs for
the servers that are working anywhere.
I think what happen is that you have one SQL Server with SPN setup properly while the other three SQL Servers with no SPN setup at all. So, you are going to use Kerberos on this particular server while NTLM on the other three.
As mentioned before, when you are using Kerberos, you have to either purge the ticket using some tools or you have to relogin in order to pick up the new group membership. You can also try to lock the screen and then unlock it. If I remember correctly, this should also refresh the ticket.
Unlike Kerberos, NTLM doesn't carry the group memberhsip data. After SQL Server authenticated the user using NTLM, it will find the authenticated user's group membership, including the new group you just added.
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.