I am trying to find out whether a user is disabled in ldap using ldapsearch utility but I have been unsuccessful so far. This is what i have got so far
ldapsearch -h hostname -D 'Service Account' -b 'basedn' sAMAccountName='disabled user' -w 'password'
# extended LDIF
#
# LDAPv3
# base <basedn> with scope subtree
# filter: sAMAccountName=disabled user
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
I have even tried with -LLL nsaccountlock it give me nothing. Its the same with a random string for user as well.
I need to find out that the user that I am specifying whether its an active or disabled user or not a user at all. Am I doing something wrong? is there another utility I can use to determine if the user is disabled
You can use this filter:
(&(objectCategory=person)(objectClass=user)(userAccountControl:1.2.840.113556.1.4.803:=2))
To find all users with the User-Account-Control value of 0x00000002
Related
I have a list of first and last name and I need to check them against my LDAP and get the emails.
I have been working with the ldap_entry and ldap_attr, but those modules don't provide information.
This will ensure that the user exist and it will try to create it, but it doesn't provide information:
- name: Make sure we have an user
ldap_entry:
dn: CN=xxx,CN=Users,DC=example,DC=com
objectClass: person
server_uri: ldap://ldap.test.com
bind_dn: CN=admin,OU=Functional Accounts,DC=example,DC=com
bind_pw: xxxxxxxxx
Is there any way to get the email from a user using ansible?
Thanks
Its not an answer, but a workaround.
I end up installing ldapsearch and I use the command option on ansible.
- name: Test ldap
command: ldapsearch -x -h ldap.test.com -D "admin" -w "xxxxxxx" -b "CN=Users,DC=example,DC=com" "cn={{item}}" -s sub "(cn=*)" mail
register: ldap_output
with_items: "{{owner_list}}"
You should be able to retrieve that information using the community.general.ldap_search Ansible module using the attrs parameter. You might need to change the name of the attribute from mail to match your LDAP server's email attribute name.
- name: Retrieve a user's mail attribute.
community.general.ldap_search:
dn: CN=xxx,CN=Users,DC=example,DC=com
attrs:
- mail
server_uri: ldap://ldap.test.com
bind_dn: CN=admin,OU=Functional Accounts,DC=example,DC=com
bind_pw: xxxxxxxxx
register: ldap_search_result
- name: Print a user's mail attribute.
ansible.builtin.debug:
msg: |
DN: {{ ldap_search_result.results[0].dn }}
mail: {{ ldap_search_result.results[0].mail }}
The community.general.ldap_search module requires the python_ldap package to be installed which in turn requires some LDAP related packaged.
I'm setting up a new SLES 12 server and want to set the default group for new users so that this is not named users but rather <username> (p.ex. user foo would be assigned to the group foo).
I found that the option USERGROUPS_ENAB in /etc/login.defs is supposed to do this job, but after I changed it to USERGROUPS_ENAB yes and tried to create a new user via yast, such new user would - according to yast- still be assigned to users.
How can I accomplish the desired behavior via yast? Or do I miss something?
After changing USERGROUPS_ENAB to yes in the /etc/login.defs file you've changed the behavior, as you are wanting, for the useradd command defaults. So, for example, you could run this command as root and it will do what you are expecting:
linux-54pe:~ # grep "USERGROUPS_ENAB" /etc/login.defs
USERGROUPS_ENAB yes
linux-54pe:~ # useradd bob
linux-54pe:~ # cat /etc/passwd | grep bob
bob:x:1003:1003::/home/bob:/bin/bash
linux-54pe:~ # cat /etc/group | grep bob
bob:!:1003:
The problem is that you are using YaST2. YaST2 is using its own default group assignment and so it doesn't respect the default changes made to useradd. In the /var/log/YaST2/y2log you can see that when I attempted to create the user frank:
2017-04-25 10:44:02 <1> linux-54pe(2871) [Perl] modules/Users.pm(Users::CommitUser):3517 commiting user 'frank', action is 'add_user', modified: 1, ldap modified: 0
2017-04-25 10:44:02 <1> linux-54pe(2871) [Perl] modules/Users.pm(Users::CommitGroup):3787 commiting group 'users', action is 'user_change_default'
Also, in the YaST2 module when you are creating the user in the Details tab you can see at the bottom that it's assigning it to its own default group parameter of users.
screenshot showing parameter
If you have a support entitlement with SUSE you can contact them to see if they are willing to submit this as a bug. At the very least they should be able to put this in as an enhancement request.
I'm changing an attribute from:
default['splunk']['auth'] = "admin:changeme"
to:
default['splunk']['auth']['username'] = "admin"
default['splunk']['auth']['password'] = "changeme"
and I want to be sure that I don't miss / forget something...
It's easy enough to be sure I didn't miss anything in cookbooks:
nickh#BONHENRY:~/Repositories/chef$ ack-grep "\[.splunk.?\]\[.auth.?\]"
cookbooks/splunk_cookbook/attributes/default.rb
36:default['splunk']['auth']['username'] = "admin"
37:default['splunk']['auth']['password'] = "changeme"
cookbooks/splunk_cookbook/attributes/README.md
72:* `node['splunk']['auth']['username']` - The default admin username to use instead of splunks "admin"
73:* `node['splunk']['auth']['password']` - The default admin password to use instead of splunks "changeme"
cookbooks/splunk_cookbook/recipes/server.rb
219: command "#{splunk_cmd} edit user admin -password #{node['splunk']['auth']['password']} -roles admin -auth admin:changeme && echo true > /opt/splunk_setup_passwd"
228: command "#{splunk_cmd} enable listen #{node['splunk']['receiver_port']} -auth #{node['splunk']['auth']['username']}:#{node['splunk']['auth']['password']}"
326: command "#{splunk_cmd} edit licenser-localslave -master_uri 'https://#{node['splunk']['dedicated_search_master']}:8089' -auth #{node['splunk']['auth']['username']}:#{node['splunk']['auth']['passwor
391: command "/opt/splunk/bin/splunk login -auth #{node['splunk']['auth']['username']}:#{node['splunk']['auth']['password']}"
cookbooks/splunk_cookbook/recipes/forwarder.rb
78:execute "#{splunk_cmd} edit user admin -password #{node['splunk']['auth']['password']} -roles admin -auth admin:changeme && echo true > /opt/splunk_setup_passwd" do
However, I'm not sure of a good way to grep/search JSON roles/environments for the same...
This works:
nickh#BONHENRY:~/Repositories/chef$ knife search environment "override_attributes_splunk_auth:*" -i
1 items found
prod-acme
However, do you have any idea why this works:
nickh#BONHENRY:~/Repositories/chef$ knife search environment "*:*" -i
108 items found
but this doesn't? :
nickh#BONHENRY:~/Repositories/chef$ knife search environment "*splunk_auth:*" -i
ERROR: knife search failed: invalid index name or query
Is there an easy / better way to do it that I'm not thinking of / unaware of? Can I change something w/ my Solr query that would make it work?
Thanks in advance :-)
Because *:* is a special case in the search system that bypasses Solr entirely. Chef's search index uses a transformed version of the query such that I don't think it would be safe to use a glob in the facet name like that. I would recommend running knife download environments/ (and similar for roles) and then doing your grep on the local JSON files.
I am having issues with Active Directory authentication via LDAP on Gitlab omnibus. I have tested the credentials and bind dn using ldapsearch and received a response with no issues, but for some reason I am not seeing any attempts at connecting when I login as an AD user on the gitlab frontend. I receive the error "Could not authorize you from Ldapmain because "Invalid credentials"." no matter if I'm using valid credentials or not.
I also receive the following from sudo gitlab-rake gitlab:check:
** Invoke gitlab:ldap:check (first_time)
** Invoke environment
** Execute gitlab:ldap:check
Checking LDAP ...
LDAP users with access to your GitLab server (only showing the first 100 results)
Server: ldapmain
Checking LDAP ... Finished
Please let me know if my explanation is not clear, or if you think that additional information would be helpful. I tried searching around and am not finding my exact issue.
My configuration is as follows:
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-EOS # remember to close this block with 'EOS' below
main: # 'main' is the GitLab 'provider ID' of this LDAP server
## label
#
# A human-friendly name for your LDAP server. It is OK to change the label later,
# for instance if you find out it is too large to fit on the web page.
#
# Example: 'Paris' or 'Acme, Ltd.'
label: 'LDAP'
host: 'myadserver.my.domain.net'
port: 389
uid: 'sAMAccountName'
method: 'plain' # "tls" or "ssl" or "plain"
bind_dn: 'CN=Gitlab,OU=Service Accounts,OU=Washington\, D.C.,OU=United States,OU=NA,DC=my,DC=domain,DC=net'
password: 'mypasswrd'
# This setting specifies if LDAP server is Active Directory LDAP server.
# For non AD servers it skips the AD specific queries.
# If your LDAP server is not AD, set this to false.
active_directory: true
# If allow_username_or_email_login is enabled, GitLab will ignore everything
# after the first '#' in the LDAP username submitted by the user on login.
#
# Example:
# - the user enters 'jane.doe#example.com' and 'p#ssw0rd' as LDAP credentials;
# - GitLab queries the LDAP server with 'jane.doe' and 'p#ssw0rd'.
#
# If you are using "uid: 'userPrincipalName'" on ActiveDirectory you need to
# disable this setting, because the userPrincipalName contains an '#'.
allow_username_or_email_login: true
# Base where we can search for users
#
# Ex. ou=People,dc=gitlab,dc=example
#
base: 'OU=Washington\, D.C.,OU=United States,OU=NA,DC=my,DC=domain,DC=net'
# Filter LDAP users
#
# Format: RFC 4515 http://tools.ietf.org/search/rfc4515
# Ex. (employeeType=developer)
#
# Note: GitLab does not support omniauth-ldap's custom filter syntax.
#
#user_filter: ''
EOS
This was, of course, a whitespace issue. See lines below:
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-EOS # remember to close this block with 'EOS' below
main: # 'main' is the GitLab 'provider ID' of this LDAP server
## label
#
# A human-friendly name for your LDAP server. It is OK to change the label later,
# for instance if you find out it is too large to fit on the web page.
#
# Example: 'Paris' or 'Acme, Ltd.'
label: 'LDAP'
I'm adding some attributes from live to staging for testing purposes, I'm using ldifde:
D:\Shared>ldifde -i -v -f attr3.ldf -j .
Connecting to "myDomain.com"
Logging in as current user using SSPI
Importing directory from file "attr3.ldf"
Loading entries
1: CN=myAttribute,CN=Schema,CN=Configuration,DC=myDomain,DC=com
Entry modified successfully.
1 entry modified successfully.
The command has completed successfully
D:\Shared>
But when I try to update it using vbs, I got:
C:\Users\update.vbs(8, 1) Active Directory: The requested operation did not
satisfy one or more constraints associated with the class of the object.
Please notice that other attributes, the original ones, are able to be updated, this issue is only for the ones I'm importing.
So, I wonder if I'm missing some step like link or detach the new attribute after imported.
This is attr3.ldf
#attr3.ldf
#adding my new attribute
dn: CN=myAttribute,CN=Schema,CN=Configuration,DC=myDomain,DC=com
changetype: add
objectClass: top
objectClass: attributeSchema
cn: my-Attribute
distinguishedName: CN=my-Attribute,CN=Schema,CN=Configuration,DC=myDomain,DC=com
instanceType: 4
whenCreated: 20100401175340.0Z
whenChanged: 20100401175341.0Z
uSNCreated: 24154
attributeID: 2.16.840.1.113805.111
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
rangeLower: 0
rangeUpper: 1
uSNChanged: 24163
showInAdvancedViewOnly: TRUE
adminDisplayName: my-Attribute
adminDescription: my-Attribute
oMSyntax: 64
searchFlags: 0
lDAPDisplayName: myAttribute
name: my-Attribute
schemaIDGUID:: tonVW6suWUu1Gev/D1pI9Q==
isMemberOfPartialAttributeSet: TRUE
objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=myDomain,DC=com
#The following attributes were removed because I was getting:
#Add error on entry starting on line 1: Unwilling To Perform
#The server side error is: 0x20e7 The modification was not permitted for security
#reasons.
#The extended server error is:
#000020E7: SvcErr: DSID-03152D2C, problem 5003 (WILL_NOT_PERFORM), data 0
#objectGUID:: eTKYtnXbCE2fPMgc8UIe0w==
#attributeSecurityGUID:: VAGN5Pi80RGHAgDAT7lgUA==
And this is the vbs code,
'update.vbs
Set objUser = GetObject("LDAP://CN=John Lennon,CN=Users,DC=myDomain,DC=com")
objUser.myAttribute="someValue" 'Also tried with integers but not luck
objUser.SetInfo
Thanks,
m0dest0.
Thank you JPBlanc, you are right, I was missing to add the attr to the class and then refresh the schema,
Register the dll, regsvr32 schmmgmt.dll
Open Run and type mmc.exe
Add Active directory schema snap-in
Right click on the class, properties and hit the Add button and so on.
Finally, refresh the schema:
C:\Users>admod -sc refreshschema
AdMod V01.17.00cpp Joe Richards (joe#joeware.net) March 2011
Modifying ROOTDSE...
DN Count: 1
Using server: myServer.myDomain.com:389
Directory: Windows Server 2008 R2
Modifying specified objects...
DN: ROOTDSE...
The command completed successfully
Regards,
Adding an attribute to the Schema is not enought, you must also add the attribute to the user class (in the schma) if you want to use it in a user object. You must modify your LDIF file:
# Define your attribute
# Reload the schema
dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-
# modify user class
Have a look to your Schema using Microsoft MMC (registering schmmgmt.dll)
If you still have trouble, I can help again tomorow morning.