A web application written in java produces links to MS Word docx documents in in WebDAV repository on a Debian Linux server. Clicking on one of these links opens MS Word and a form is shown to put in authentication information. Then the document is opend and can be edited and saved.
Clicking on a link for the next time, one has to go through the whole process of autheticating (fill in the form) again.
Choosing 'Remember me' did not work. They write, the form should then be prefilled, but it isn't.
I want to get rid of this. Most tipps describe that this would be a problem with Basic Auth or Digest Auth and when using Kerberos it could be solved.
After installing Kerberos MIT on this server, I am able to authentication like before, but the problem still exists.
Does anyone have a hint or a solution for this?
Is there a configuration for MS Word/MS Office Upload center one has to go through?
Does one have to place any cretentials on the client?
...?
Configuration
Server version: Apache/2.4.38 (Debian)
MS Word 2013
After struggling many hours I get the Office login form pre filled now.
The solution was to delete all Generic Credetials in Windows Credentials which contain MicrosoftOffice and SSO_POP_Device and the credetial for the our server.
After that I established our server as network drive, which has the sideeffect that my credetials are stored in Windows Credentials, which leads to pre fill the login form.
But the problem that single sign on is not working still exists.
Related
I am attempting to set up an IIS 6.0 application running on Windows Server 2003 to use impersonation in order to avoid having to give users direct read/write access to the shared folders where the DB and web pages are stored. Can anyone provide me with details of how this can be set up to work in conjunction with Windows Integrated Authentication?
So far, I can tell that the web.config file (not sure whether it's the correct one) has the two lines mentioned on this thread (Impersonation in IIS 7.0) to allow impersonation and use the Windows logon method. However, users are still prompted for a logon and then told they are not authorized to view web pages. They can view pages if we turn anonymous logon "on", but then their user credentials aren't passed on to the site and therefore they can't access most of it.
I'm fairly inexperienced, so I'm a bit lost here. Thank you very much in advance for the help!
Thanks to intervention from Microsoft (definitely worth the flat fee they charge per incident), we were able to identify the problem. Instead of using the network path to identify the website location on the "Home Directory" tab of the IIS properties, we were using the local drive path. That was all that needed to be changed.
Once we switched to the network path and added a dedicated service account to "Connect As...", impersonation started working right away. Users pass their logged on credentials via integrated authentication (no logon required) and the service account takes care of executing their actions on the database file.
Access to the shared folder is limited to a brief list of administrators, and data access on the web application is limited based on user names.
If anyone is stuck with this and needs help, let me know!
I'm trying to open a Microsoft Access 2000 .MDB file to migrate it, as it is currently being used by somebody's ten-year-old VB app that's fallen by the way side on an NT server and whose author is long gone. Back in September I copied the MDB file over to a nearby XP machine (because that has Access installed), and when it asked for a name and password, was able to open it then using those of the Windows XP account I was logged in as.
However, since I tried again in November, it suddenly will no longer accept that username/password pair and everyone swears noone has touched the machine. I've tried a blank username, the login/pass of the "Administrator" account on the NT server from which I got it, as well as all of those on the XP machine I previously opened it on.
I tried running a couple password-recovery apps on it such as Rixler Access Password Recovery and Nirsoft's "accesspv.exe", and they both say that the file is not password-protected. So it's not a "database" password per se, it just wants some account info and I have no idea even what username it wants.
I've read up on what I could find in the way of MDW files; finding 3 of such on the XP workstation, I tried renaming them all in case that's where it's trying to look for account names, but the result is also the same.
The half-broken VB app that it was built for is apparently still opening and using the database fine; alas I've not found its source code.
Anyone know what Access 2000 wants as far as credentials in a non-password-protected MDB file, and how to get back in?
Thanks.
Solved with MDB Tools. That would have been pretty handy about five months ago.
My company has a MediaWiki setup which we are looking to make [partially] client accessible. Ideally each client would be able to see only their own page. Our wiki requires the user to be logged into view or edit, and we have the LDAP plugin (This one, specifically) so we can use our Active Directory credentials.
I see this question has come up before a few years ago, but I didn't see an question dealing with LDAP in particular. Can we manage a specific AD account if we give clients one on our domain for this purpose? Alternatively, is there a way to give clients a login directly into the wiki (sort of like logging locally into the computer, instead of the domain), that we could control the access rights of?
For reference: we are on MediaWiki version 1.19.1, PHP version 5.3.15, MySQL version 5.0.96-winx64, and the installation is running on Windows Server 2008 R2 x64 (IIS 7.5).
Thanks very much for the help!
You can use local accounts in addition to the LDAP accounts to log users in. You have to set $wgLDAPUseLocal to true in your LocalSettings.php. Basically, it adds another option to the domain drop down box on the login form that says "local". Users that want to log in with a local wiki account use that. I would also disable account creation on the wiki and create accounts manually for your clients.
Regardless of whether you use local accounts or AD accounts, for page-level access control, you would have to use one of these extensions. Extension:AccessControl seems to be a popular one.
Having an issue with random individuals trying to access an intranet site with a security certificate. Most users are able to simply select their Smartcard/CAC certificate, enter the pin number and then are granted access to the site's pages.
However, random individuals enter their pin and then are immediately re-prompted by the IE alert dialogue to enter their domain username and password. If they don't enter their network domain username and MS password, then they receive a 401.1 Unauthorized.
I am confused as to why these certain users (who are selecting the same certificates as the successful ones) are being prompted for their domain name/pwd. Furthermore, they're able to access other sites which require a CAC to get past the security certificate.
Possible that a user token is unable to be established via a CAC card for the particular site, but not sure why. Since these users are getting a 401.1, then somehow their identity associated with their CAC credentials is not validating.
In IIS:
Anonymous users are not allowed (unchecked).
128-bit encryption is required with SSL.
Integrated Windows Authentication is checked.
Accepting client certificates
In the site's web.config file all users are allowed and only anonymous are denied.
The exact same setup is present on the development box without any issues at all, indicating to me that the problem resides on the production server's ability to properly receive/handle CAC information from those individuals or that something funky is going on with the way the security certificate is relating to the client's CAC x.509 certificate.
A little more information that may be of use: the browser prompt that initially asks for the CAC has nothing to do with the code of the site, but rather is enabled by applying the security certificate to a site in IIS; thus indicating to me that there is something written into the certificate that looks for client certificates tied to the ActivClient agent via the browser???
Then again, I probably have no idea what i'm talking about, just throwing a bone here to see if anyone has had the same issue or has any ideas.
Thanks in advance for any input, questions, or ideas.
The problem was a stinking DLL that serves to help parse long URL's with many aliases (dots). The faulty DLL had been written into many people's re-image of their computers. The violating computer re-freshes contained an old version of a DLL used by Internet Explorer called URLMON.dll. The version of the DLL you need should end in '21073', but the one included on the faulty images listed above ends in '19.....'.
You can confirm this by going into IE7 and clicking on Help > About Internet Explorer > System Information (btn on bottom) > Internet Settings > Internet Explorer > File Versions > urlmon.dll
Updating this DLL has shown to fix the issue with secure SSL sites having problems validating CAC/pin entry that have long DNS entries (such as https://something.something.something.something.something.something).
There is an IE7 hotfix for this, but it will only install if you don't have ServicePack 3. If you do have SP3, , you cannot run the needed Hotfix, b/c it assumes that SP3 has already put into place the correct DLL.
1. Uninstall SP3
2. Reboot
3. Install the IE7 Hotfix
4. Reboot
5. Run Microsoft Updates via the Window MS updates website
Sucks, but that's what you get with crappy software like IE run on a deficient operating system, then coupled with software that's limited in it's abilities to truly talk to the operating system.
Check the functioning of the card with other applications.
Also check that the certificates are valid (not expired) and otherwise similar - same issuer, PIN not locked etc.
I understand your development environment works as you want and that your production environment is not.
Have you tried to reproduce the error in another environment to confirm which behavior is consistent?
Had a very similar problem that was solved by bypassing the proxy server. Try adding it to the exemption list.
In IE, go to:
Tools | Internet Options | Connections | Lan Settings | Advanced
Add site to exemptions list.
May not work for you, but could be worth a try. Like I said, it worked for me with a very similar issue.
Hi Guys any help would be much appreciated.
We have an application that’s installed at several locations but we are having an issue at one particular site. In short the application settings (My.) are not being saved after a reboot. The application is build in VB.Net v3.5 Framework and we are not experiencing any issues elsewhere.
This particular site is using roaming profiles and the network administrator ensures us that the correct permissions are applied to the user account(s) and all application data is being saved to the server. I’ve asked the network admin to check for the existence of the user settings file user.config in the Application Data directory and he says it doesn’t exist.
In our application we store the connection string to the database in the application settings under the user scope. If no connection string is present or if one is present and a connection to the database cannot be made then a form is shown asking the user for the database credentials. Each morning when the users boot the machine and opens the application for the first time they are asked for these credentials but if they close the application and restart it they are not asked for them. This indicates to us that the settings are being saved but once the pc is rebooted and the application is opened for the first time they are asked for the database credentials. This seems like the settings are not persisting after a reboot.
Any thoughts/feedback would be much appreciated.
I'm wondering if it's Code Access Security preventing the file from being written?
If the sysadmin at trouble site has implemented group policy folder redirection, the user's local/roaming profile could be getting stored on a network fileshare. Code Access Security is fairly picky about letting code read/write to/from network resources.
I'm sorry that I don't have more details than this, and I didn't find any sure-fire hits on google, but searching for "code access security", "fulltrust" and any network/fileshare keywords you can think of may get you farther.