I've been attempting to authenticate to an Active Directory Windows 2008 server with ldap.js. The only goal is to authenticate to the server, and I am using the client side stuff (not creating new server, which is what all the documentation is about). I'm totally new to LDAP, and as such, authenticating with username "MYDOMAIN\myuser" does not work in ldap.js, but does in ldapsearch: ldapsearch -H ldap://192.168.1.212:389 -x -D 'MYDOMAIN\myuser' -w pa33w0rd -LLL -b "dc=mydomain" '(sAMAccountName=myuser)' which authenticates successfully but then spits out Referral (10).
trying that in ldap.js with client.bind("MYDOMAIN\myuser", 'pa33w0rd', function(err) { ... } ); fails with 49 InvalidCredentialsError 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, ...
Attempting to re-write MYDOMAIN\myuser as a Distingushed Name dn: cn=myuser, dc=mydomain also fails with auth errors also in ldap search. What is the proper way to convert DOMAIN\USER (domain backslash user format) to a DN?
From http://www.rlmueller.net/NameTranslateFAQ.htm:
Distinguished Names - format as specified in RFC 1779. For example cn=TestUser,ou=Sales,dc=MyDomain,dc=com.
NT format - the name format used in Windows NT 4.0. For example MyDomain\TestUser, where MyDomain is the NetBIOS name of the domain and TestUser is the NT name of the object (the pre-Windows 2000 name). The value of the sAMAccountName attribute is the NT name of the object.
Thus, the NT format (domain backslash user) login name MYDOMAIN\myuser can map to cn=myuser,cn=Users,dc=mydomain,dc=com or cn=myuser,cn=Users,dc=mydomain,dc=local or a bunch of others. I suggest you look at the hosts file or DNS domain name of the AD server. You should also change the -b (base) to include the dc=com or dc=local, or whatever to fix the referral error.
Related
I have a Nextcloud installation, with users stored in an external database, and this works fine with this app : https://apps.nextcloud.com/apps/user_sql
With that in place, I can login on my Nextcloud instance via the login form provided by Nextcloud.
I need to autolog the users when they come from another app.
I've written a PHP script, placed at the root of my Nextcloud installation, and it gets called by other internal apps of my company.
This script receives a userId and a token in the URL. After a successful check (no need to get in the details here), this script should log the user in.
Which API should I call to get the user logged in?
I tried the following, without success:
OC_User::login(...)
OC_User::getUserSession()->login(...)
Is there a way to trigger a valid login, so that I can get the users logged in?
Thank you for your answers, guys!
$user = '';
$pass = '';
$s = \OC::$server->getUserSession();
if (!$s->isLoggedin()) $s->login($user, $pass);
else $s->logout();
Placing this at /index.php and before calling OC::handleRequest() does the trick. It doesn`t work as expected but you could try to continue from here.
PD: Nextcloud Server v14.0.0 Alpha
I'm meeting troubles with Squid Kerberos auth and the Squidguard ldapusersearch who I use to apply acl by Active Directory groups membership.
The problem is :
Squid and Squidguard see my user as : user#domain.local so the '%s' variable of squidguard is 'user#domain.local'
Into my ldap query there is no default property who can interpret this string.
Example :
src ldap {
ldapusersearch ldap://dc1.domain.local:3268/dc=domain,dc=local?sAMAccountName?sub?(&(sAMAccountName=%s)(memberOf=CN=group,OU=Groups,DC=domain,DC=local))
}
And sAMAccountName should be only 'user' and not 'user#domain.local' !!!
So I found a solution but It's not very comfortable :
I edit a unused attribute of the AD user and I write into it my kerberos login so my conf looks like this :
src ldap {
ldapusersearch ldap://dc1.domain.local:3268/dc=domain,dc=local?displayNamePrintable?sub?(&(displayNamePrintable=%s)(memberOf=CN=group,OU=Groups,DC=domain,DC=local))
}
And it works !!!
Anyone an idea to bypass the need to create a custom attribute in AD who contents ?
I precise that userPrincipalName is the same as the email and can't interpret Kerberos login.
Thanks all !!!
i am using Squid Version 3.4.5-20140514-r13135 with squidguard 1.5-beta and the strip-domain-realm Patch of Mathieu Parent which is able to strip the Domain and Strip the Realm.
So the users appear as "user" and not as "user#KERBEROSDOMAIN"
Here is an exmaple configuration thats working for me
dbhome /var/lib/squidGuard/db
logdir /var/log/squidGuard
ldapbinddn squidguard#domain.tld
ldapbindpass squidguardpass
ldapprotover 3
ldapcachetime 2400
stripntdomain true
striprealm true
src users {
ldapusersearch "ldap://ldapserver:3268/dc=ADDomain,dc=com?sAMAccountName?sub?(&(sAMAccountName=%s)(memberOf=CN=SQUID_USERS,OU=Squid_Groups,OU=Groups,DC=ADDomain,DC=com))"
}
I'm currently setting up a gitlab server using a LDAP backend.
When I try to login as a user present in the LDAP db, I get the following error:
"Could not authorize you from LDAP because: "Undefined method 'persisted?' for #"
Peeking into the source code (specifically app/controllers/omniauth_callbacks_controller.rb) the villain seems to be:
#user = Gitlab::LDAP::User.find_or_create(oauth)
#user.remember_me = true if #user.persisted?
It is totally correct for him to fail here because there is no method persisted? (neither in lib/gitlab/ldap/user.rb nor lib/gitlab/oauth/user.rb). Changing the second line to
#user.remember_me = false #true if #user.persisted?
doesn't work either since remember_me is an invalid function for ruby.
I really have no clue about ruby, let alone Ruby On Rails, so I stopped digging here.
Since I certainly am not the first person to try using LDAP auth in gitlab I consider this an error on my side. Since authentication seems to work (if I enter a false password for the user gitlab happily tells me so), I don't have any idea where to start looking.
I appreciate any help from you guys,
Best Richard
Edit: My gitlab.yml is here.
Solved the problem myself. The database lookup yielded a nil object due to the user creation failing (whenever a ldap user logs in, gitlab uses the ldap data to fill its own database).
During creation of the user database entry the query got an invalid email entry resulting in a failed insert query. Unfortunately this was very hard to debug.
In case anyone should have this problem, try changing the following code in lib/gitlab/oauth/user.rb:
begin
user.save!
rescue ActiveRecord::RecordInvalid => e
raise_error ("(OAuth) Error #{e.to_s}") # <-- add this line
log.info "(OAuth) Email #{e.record.errors[:email]}. Username #{e.record.errors[:username]}"
return nil, e.record.errors
end
This will - in case gitlab is not able to add your user - print the error message the database backend returned as the usual red error banner when trying to log in. Keep in mind to remove this line when you no longer need it.
I can suggest a patch (tested on Gitlab 7.1.0). This code sets the gitlab_rails['ldap_uid'] as username when a ldap user is connecting for the first time :
in /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/oauth/user.rb (see INCLUDE START and STOP) :
user = model.build_user(opts)
user.skip_confirmation!
# Services like twitter and github does not return email via oauth
# In this case we generate temporary email and force user to fill it later
if user.email.blank?
user.generate_tmp_oauth_email
elsif provider != "ldap"
# Google oauth returns email but dont return nickname
# So we use part of email as username for new user
# For LDAP, username is already set to the user's
# uid/userid/sAMAccountName.
email_username = email.match(/^[^#]*/)[0]
# Strip apostrophes since they are disallowed as part of username
user.username = email_username.gsub("'", "")
else
# INCLUDE START
# if LDAP config "ldap_uid" is set : we pick this attribute to set the username :
if ldap_conf['uid'].present?
user.username = auth.extra.raw_info.send(ldap_conf['uid'])[0]
end
# INCLUDE STOP
end
begin
user.save!
In my case the problem was importing (copying file) fro old gitlab repositories to new one.
Gitlab wasn't able to create clean folder for the new user.
Solution:
remove imported repositories
create new, empty repository by first login with LDAP credentials
read your PRIVATE-TOKEN
start gitlab server on your repository ie. 'git daemon --verbose --export-all'
import data from old gitlab using API:
curl -X POST --header "PRIVATE-TOKEN: xxxxxffxxxyyxxxxzzz" http://testserver07.lq/api/v3/projects"?name=project01&import_url=git://localhost/var/opt/gitlab/git-data/repositories-old/repos/project01.git"
First, check if your email address in Gitlab DB is correct:
# login to Gitlab DB (MySql)
mysql -u gitlab gitlabhq_production -p
# check user email address
select email from users where username like 'foo';
Then remove stored LDAP objects from Gitlab DB for the user:
# clear ldap data
update users set extern_uid = '' where username = 'foo';
On next login Gitlab write a new extern_uid.
I'm working on an application supported by CouchDB. Essentially, I want to create a database for each individual user of my app. To accomplish this, the admin user will create the database, but going forward, the user will need to access their database (using HTTP Auth over SSL). I've been having a hell of a time figuring this out.
The best resource I have found is in the CouchDB wiki, at this link:
http://wiki.apache.org/couchdb/Security_Features_Overview#Authorization
It suggests that you can set per-database authorization by creating a document called "_security" to which you add a hash of admins and readers. When I attempt to create that document, the message I get back is "Bad special document member: _security".
$ curl -X GET http://localhost:5984
{"couchdb":"Welcome","version":"1.0.1"}
Any help would be appreciated!
Cheers,
Aaron.
There should be no problem with that aproach.
Let's say you have a database "test", and have an admin account already:
curl -X PUT http://localhost:5984/test -u "admin:123"
Now you can create a _security document for it:
curl -X PUT http://localhost:5984/test/_security -u "admin:123" -d '{"admins":{"names":[], "roles":[]}, "readers":{"names":["joe"],"roles":[]}}'
Them only the user "joe" will be able to read the database. To create the user you must have already the sha1 hashed password:
curl -X POST http://localhost:5984/_users -d '{"_id":"org.couchdb.user:joe","type":"user","name":"joe","roles":[],"password_sha":"c348c1794df04a0473a11234389e74a236833822", "salt":"1"}' -H "Content-Type: application/json"
This user have the password "123" hashed using sha1 with salt "1" (sha1("123"+"1")), so he can read the database:
curl -X GET http://localhost:5984/test -u "joe:123"
He can read any document now on that database, and no other user (but him and admin) can.
UPDATED: Writer security
The above method issues the reader problem, but the reader permission here actually mean "read/write common docs", so it allows to write docs except for design-docs. The "admin"s in the _security doc are allowed to write do design-docs in this database.
The other approach, as taken from your own answer, is the "validate_doc_update", you can have a validate_doc_update as follow in a file:
function(new_doc, old_doc, userCtx) {
if(!userCtx || userCtx.name != "joe") {
throw({forbidden: "Bad user"});
}
}
And push it into a couchdb design:
curl -X PUT http://localhost:5984/test/_design/security -d "{ \"validate_doc_update\": \"function(new_doc,doc,userCtx) { if(userCtx || userCtx.name != 'joe') {throw({forbidden: 'Bad user'})}}\"}" --user 'admin:123'
Them "joe" can write to the database using Basic Authentication:
curl -X PUT http://localhost:5984/test/foobar -d '{"foo":"bar"}' -u 'joe:123'
As you also addressed you can use the _session api to get a cookie for authentication:
curl http://localhost:5984/_session -v -X POST -d 'name=joe&password=123' -H "Content-Type: application/x-www-form-urlencodeddata"
This will return a header like:
Set-Cookie: AuthSession=am9lOjRDRDE1NzQ1Oj_xIexerFtLI6EWrBN8IWYWoDRz; Version=1; Path=/; HttpOnly
So you can include the cookie "AuthSession=am9lOjRDRDE1NzQ1Oj_xIexerFtLI6EWrBN8IWYWoDRz" in your next requests and they will be authenticated.
I've been doing more research and testing, and I want to summarize where I've gotten to, and what still isn't working for me.
First off, apologies for those who read this question: I was looking for ways to set permissions for people to write, not read, the database. It turns out be be a big difference: the techniques for creating a "reader" are entirely different from creating a "writer" (that term actually doesn't exist, though I wonder why).
In brief: you have to add a user to the _users database, which is a list of the users that have access to any database in your CouchDB instance. I was able to do that by issuing a command similar to:
curl -X PUT http://admin:password#localhost:5984/_users/org.couchdb.user:username -d '{"type":"user", "hashed_password":"2bf184a2d152aad139dc4facd7710ee848c2af27", "name":"username", "roles":[]}'
Note you need to apparently namespace the user name with the "org.couchdb.user" prefix. I used a Ruby hashing method to get the hashed_password value:
require 'digest/sha1'
pass_hash = Digest::SHA1.hexdigest(password)
This gets an apparently valid user into the database. The next step is to assign that user as a "writer" (ha, there it is again!) for the new database that I created. So I might do something like:
curl -X PUT http://admin:password#localhost:5984/newdatabase
and then
curl -X PUT http://admin:password#localhost:5984/newdatabase/_design/security -d #security.json
That .json file contains a Javascript function for the "validate_doc_update" key, and that function looks like this:
function(new_doc, old_doc, userCtx) {
if(userCtx.name != username) {
throw({forbidden: "Please log in first."});
}
}
It's roundabout, but it makes sense. However, I now am running into a problem: apparently the userCtx variable doesn't get populated until the user is authenticated. This article suggests that all you have to do is pass the credentials through an HTTP request to a special _session database, like so:
curl -X POST http://username:password#localhost:5984/_session
I can do that for my admin user, and the userCtx var will be populated. But for my newly-created user, it fails:
$ curl http://org.couchdb.user:username:password#localhost:5984/_session
{"ok":true,"userCtx":{"name":null,"roles":[]},"info":{"authentication_db":"_users","authentication_handlers":["cookie","oauth","default"]}}
Note the userCtx hash is null. I wonder if that namespace thing is causing the problem? It's got a freakin' colon in it, so maybe there's some confusion about the password? I've tried making it without the namespace, and it doesn't work at all; at least here my request appears to be hitting the database and getting a response.
I'm stuck at this point. If anyone can check my assumptions and progress thus far, I hope we can all figure out how to make this work.
Thanks!
Aaron.
You may want to check out Matt Woodward's - The Definitive Guide to CouchDB Authentication and Security http://blog.mattwoodward.com/2012/03/definitive-guide-to-couchdb.html
I am trying to use System.Net.WebClient in a WinForms application to upload a file to an IIS6 server which has Windows Authentication as
it only 'Authentication' method.
WebClient myWebClient = new WebClient();
myWebClient.Credentials = new System.Net.NetworkCredential(#"boxname\peter", "mypassword");
byte[] responseArray = myWebClient.UploadFile("http://localhost/upload.aspx", fileName);
I get a 'The remote server returned an error: (401) Unauthorized', actually it is a 401.2
Both client and IIS are on the same Windows Server 2003 Dev machine.
When I try to open the page in Firefox and enter the same correct credentials as in the code, the page comes up.
However when using IE8, I get the same 401.2 error.
Tried Chrome and Opera and they both work.
I have 'Enable Integrated Windows Authentication' enabled in the IE Internet options.
The Security Event Log has a Failure Audit:
Logon Failure:
Reason: An error occurred during logon
User Name: peter
Domain: boxname
Logon Type: 3
Logon Process: ÈùÄ
Authentication Package: NTLM
Workstation Name: boxname
Status code: 0xC000006D
Substatus code: 0x0
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 127.0.0.1
Source Port: 1476
I used Process Monitor and Fiddler to investigate but to no avail.
Why would this work for 3rd party browsers but not with IE or System.Net.WebClient?
I have seen a similar issue, where the Integrated / NTLM security will only work if you are accessing the host by machine name or localhost. In fact, it is a [poorly] document feature in Windows that is designed to protect against "reflection attacks".
Basically, you need to create a registry key on the machine that is trying to access the server, and whitelist the domain you are trying to hit. Each host name / FQDN needs to be on it's own line - there are no wildcards and the name must match exactly. From the KB Article:
Click Start, click Run, type regedit, and then click OK.
In Registry Editor, locate and then click the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Right-click MSV1_0, point to New, and then click Multi-String Value.
Type BackConnectionHostNames, and then press ENTER.
Right-click BackConnectionHostNames, and then click Modify.
In the Value data box, type the host name or the host names for the sites that are on the local computer, and then click OK.
Exit Registry Editor, and then restart the computer.
http://support.microsoft.com/kb/956158/en-us
Have you tried ...
new NetworkCredential( "peter", "password", "boxname" );
You might also try ...
var credCache = new CredentialCache();
credCache.Add( new Uri ("http://localhost/upload.aspx"),
"Negotiate",
new NetworkCredential("peter", "password", "boxname"));
wc.Credentials = credCache;
Also, according to this it may be that IIS is configured wrong. Try replacing "Negotiate" with "Basic" in the above and checking your IIS config for the website. There's also a bunch of possible causes here.
Try going into IE's options and explicitly add the site to the Intranet Zone. Then re-run the program. You should also not run the program from an administrator login. This may trigger the Enhanced Security Configuration for Internet Explorer.
It could explain why you can hit the site with Firefox and Opera, but not with IE or WebClient.
Without knowing your IIS deployment, and assuming that you have the correct authorization rules for upload set in IIS (e.g. the right allow* ACL's on the right dirs you are trying to upload content to, etc), first thing I would try is to set UseDefaultCredentials to true instead of explicitly set Credential. (Maybe you think you are accessing the server with the Credentials you are setting but that's not the case? That would be possible if this works.)
This is a very common scenario, so I would focus on IIS authorization rules for the directory in which you are trying to upload the file, the actual ACL's on that directory. For ex. is your site impersonating or not? if it is, then you have to have actual ACL's on that dir, otherwise whatever account app pool is running on.