I created a person document with a HTTP password.
In a database I have set Anonymous access to "No Access" and Default to "Author".
When I try to login to the database I get the following error:
HTTP Web Server: Access Denied Exception [/db.nsf] CN=User Name/O=Org
I used google and found some articles incl http://www-01.ibm.com/support/docview.wss?uid=swg21194981 but they don't contain the fix. The user is not in the "deny access" server groups.
I created/updated 10 other person documents, all 10 can login without any issue.
It WAS the deny access server issue. The person record had multiple names and one of the old names was denied.
A bit strange as the user has no issues accessing the Domino server using the Notes Client.
Regarding Notes and browser differences with multiple records, I seem to recall that Notes clients went down a view's index, and browser went up the view's index (intentionally), or vice versa.
This was intentional behavior, so that two elements could have the same name, but be devoted to one or the other client.
Related
Ok, one physical server running Hyper-V. One VM is for the SQL 2016 DB. Another VM is for the web based application that talks to the DB. A third VM that is used as the file server. All files are stored on the file server.
The file location that needs to be bulk inserted is shared with the DB Service Accounts (currently set to specifically made domain accounts - one for each service).
The file can't be imported - access is denied. I've tried setting the share to Everyone - still doesn't work. I even changed the Security Policy to allow Anonymous users the same permissions as Everyone - still doesn't work.
I don't know how to go about this Delegation method so not sure what to do there.
What else can I do to get a simple file to import into a DB?
Have you enabled kerberos? If the connection is coming in as Anonymous, dosent it mean that the connection is using NTLM and its a double hop issue?
The Plan
Have HR personnel dump an Excel file of payroll Job Titles to a network share, add that file as a Linked Server in SSMS, use those titles in my ASP.Net web forms. Using a Linked Server instead of importing data to allow HR to update the Job Titles file at their discretion.
The Problem
I can create the Linked Server and query it without issue, so long as I'm in SSMS with Windows Authentication. But, if I try to access the linked server using a SQL account, I first get the error:
Access to the remote server is denied because no login-mapping exists (Error 7416)
The SQL account being used is the same account my web forms use for everything else. The fact that this SQL account doesn't have file permissions isn't surprising though, so an adjustment to the Linked Server's security should do the trick.
The Problem (part 2)
To reduce the number of variables, I moved the Excel file so it's on the same machine as my SQL Server. I'm logged into the machine and logged into SSMS with my domain admin account.
I access the Linked Server's security tab and, to try and cast the widest net possible, I leave the local login (top part) blank and head straight to "Be made with this security context:" and proceed to provide my domain admin credentials. I hit OK, and I get the following:
Not a valid account name or password (Error 7399)
I know the account name and password are good, so what gives?
Other Things
Folks who've ran into similar things have been instructed to change the logon account being used for the SQL Server service, which I've done using my domain admin account (for troubleshooting, atm). This did not fix the problem.
This is what the Linked Server code looks like, although I created it via the GUI (included for sake of completeness):
EXEC master.dbo.sp_addlinkedserver #server = N'ADP_TITLES', #srvproduct=N'', #provider=N'Microsoft.ACE.OLEDB.12.0', #datasrc=N'C:\JOB_TITLE_EXPORT.xlsx', #provstr=N'Excel 12.0 Xml'
EXEC master.dbo.sp_addlinkedsrvlogin #rmtsrvname=N'ADP_TITLES',#useself=N'False',#locallogin=NULL,#rmtuser=N'DOMAIN\username',#rmtpassword='########'
The solution appears to be entering "admin" for the remote login, and leave the password blank.
This only works, however, if the file is stored locally. If it's on the network, I still get a 7399 error, but instead of saying the issue is the account name/password, it now says the issue is unspecified.
I can make my project work with a local file though. Since I'll be moving forward with that, I have no need to solicit additional answers.
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.
The problem is I have full access to the server where the Sharepoint site is hosted etc, however all i've ever done is maintained the site. I didn't set it up.
There is now an issue where Sharepoint can't connect to the Config or Content databases. I don't know which of our servers run these, so is there anyway I can find out, maybe from a config file or anything which server/database I need to check.
Other websites on the web server are still running fine, I know the database isn't on that same server because i've checked.
Any ideas?
I normally find the easiest way is to look at the site collections settings in Central Administration (which you should be able to access if you have root access to the server WSS 3.0 runs on)
Take the following steps once in the Central Administration site:
Go into Application Management
Go into Content Databases
Select your web application using the selector which is orange in the top right of the main content of the page
Click the name of the database displayed
Once you are at the final point you should see at the top information for Database Server and SQL Server Database Name. Hopefully this should point you in the right direction of where your database is being stored.
If your access to the database content database is cut due to incorrect login details to the SQL server (i.e. the SA account's password has changed), the SQL credentials can be updated here too for the selected content database.
Hope this helps.
Check out the Event Viewer Log. There would be an entry similar like this:
Event Type: Error
Event Source: Windows SharePoint Services 3
Event Category: Database
Event ID: 3760
Date: 4/16/2009
Time: 11:51:07 AM
User: N/A
Computer: IMIAPP03
Description:
SQL database **'STS_Config'** on SQL Server instance 'np:\\.\pipe\MSSQL$Microsoft##SSEE\sql\query' not found. Additional error information from SQL Server is included below.
Cannot open database "STS_Config" requested by the login. The login failed.
Login failed for user 'NT AUTHORITY\NETWORK SERVICE'.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
I have an asp.net application directory, and I want to use anonymous authentication in the Directory Sercurity tab.
If I use the pre-Windows 2000 style DOMAIN\USERNAME for the username, everything is fine.
If I use the AD-style (UPN) usename#domain.local, then I get a 401.1 failed login.
I've tried a number of variations, but can't get it to work. If I select the user from the Browse box, the AD name comes up in the box, but the pre-Windows 2000 name is filled-in. Likewise for SQL Server 2005.
It seems that the UPN isn't 'real', is this right? Given that it's not required and doesn't have to be unique; it seems very odd.
Am I correct, in that this is not supported? Would IIS 7 make any difference?
I wish to do this, because the limit of 20 characters for the pre-Windows 2000 username is insufficient for the role-based security I wish to apply for different webservices (the application directories) coming off this website.
UPN suffixes should work, althouh there is a bug which occurs when there is a service pack difference between the IIS box and the domain controller. There is a patch for it. This link discusses the issue in detail.
Are you sure it's domain.local and not domain.com. If the domain\username is working, then username#domain.com should work.
Update 1:
I have tried it on Windows 2003 sp 2. In the login "directory security" I have checked the enable anonymous access check box ( and only this box ) and put ausername#mydomain.com and the ausername password. The site is plain asp.net without sql backend.
Are you able to login to the server with the usename#domain.local ?
Can you test this on different domain? It may be some wired dns resolution problem.
Update 0:
I tested it on iis 6 and the username#domain.com combination works fine on my machine.
About the "realnes" of the names. No name is "real" the actual account is just a GUID. The names are just for convenience.