We can create objects like Users and Groups via LDAP.
The question is how to create keytab file using LDAP?
I need somehow to run the following command and obtain the ffs.keytab file using LDAP.
ktpass -princ HTTP/xyzid.xzu.io#DC.YOURADDOMAIN.LINK -mapuser
ffs#DC.YOURADDOMAIN.LINK -crypto ALL -ptype KRB5_NT_PRINCIPAL -pass
+rndPass -out c:\ffs.keytab
What do you think about Kerberos.NET? This library contains several features for integrate LDAP with dot net core applications, include create keytab files. Here have one thread commented by Steve Syfuhs, principal contributor of this library.
LDAP is a protocol to access the directory but it cannot be used to run some command on the server. So the answer for your question is you cannot create keytab using LDAP
For better understanding the use of Kerberos and LDAP, check the below link
https://stackoverflow.com/a/46188971/3496666
You can create objects like users and groups using LDAP because it was the actual purpose for LDAP designed to access the directory and make the changes within the directory whereas keytab is mainly used for authentication and getting auth ticket without the need for password.
If you could explain the purpose for your requirement, some may have solution for you in different way but not using LDAP.
Related
I have some understanding problems of LDAP.
When i use an Active Directory Server i can bind with username#domain and a password.
When i use ApacheDS i must give it the full DN of the user and a password.
So i have the folowing Questions:
How do i find out the full dn of a User on a ApacheDS Server with
anonymous privilegs and only the knowledge of username, domain (and
password)?
Is this evenposible? Is the ApacheDS Server even made to be an
alternative to Active Directory?
Generally, LDAP authentication is done in two steps:
Map a given unique user identifier (uid) to its distinguished name using a search operation with a filter like (&(objectClass=user)(uid=%s))
Use a bind operation with that dn to authenticate against your LDAP server.
Active Directory comes with a convenience feature: You can bind using a couple of supported identifiers and AD will do the mapping internally for you.
ApacheDS isn't a plug-and-play substitute for AD, but it's extensible. A Java developer can easily write an authentication interceptor providing the same internal mapping as AD.
As marabu said you can simulate the authentication using a search on the directory before doing the bind.
You can also look for SASL authentication which provides other ways to authenticate.
Here are a list of ApacheDS supported SASL mechanism : http://directory.apache.org/apacheds/advanced-ug/4.1.2-sasl-authn.html
I'm currently using mod_authnz_ldap to enable HTTP Basic Authentication against Active Directory for a VirtualHost. Based on the documentation it is recommended to set a user and password to enable the resolving of user DNs for the bind.
However AD offers methods to bind users without using a separate account for searching the directory in front. E.g. you can suffix a username with the Domain like that: username#domain and AD resolves the DN behind the scenes.
As I don't want to create accounts for my web servers I'm curious if there is a way to configure Apache2 using mod_authnz_ldap or another module to bind against AD without using an search account.
You can take advantage of the supported Active Directory object name forms for a simple bind, and skip the search for a user's DN by using directive AuthLDAPInitialBindAsUser with module mod_authnz_ldap.
I am going to use Rundeck in production.
While reading docs, I found that users management is based on local ACL files.
And AD authentication is available.
My question is: Is it possible to manage users access to Jobs and Nodes by AD groups?
Fox example:
AD groups: rundeck_restrat_svcName1, rundeck_restrat_svcName2, ect..
Thanks for any information.
Yes.. You can do that.
1, Create a jaas configuration file for AD, say jaas-AD.conf at /etc/rundeck folder like this
2, Modify the profile file's two lines.
export RDECK_JVM="-Djava.security.auth.login.config=/etc/rundeck/jaas-AD.conf
-Dloginmodule.name=activedirectory
3,In AD create a new group, say rundeck_users and create an .aclpolicy file to set the ACL. There you have to use group as rundeck_users. You can create .aclpolicy file yml frame by rd-acl binary
My current C program authenticates across multiple active directory domains using sAMAccountName/domain. It uses a config file to map the domain to the correct VIP (Virtual IP) server to bind and query to. I am modifying it to use userPrincipalName, which is an email address. The domain portion of the userPrincipalName is not necessarily the same domain that maps to the VIP servers.
Using my account, I am able to bind to any one of the VIP servers, but since I am not necessarily an Active Directory member on that server, I am unable to query. Right now, I have to iterate through each server until I find the one which I am a member of. This is not my ideal approach.
My question is, is there a way to retrieve what Active Directory domain I am a member of using just the userPrincipalName? I have read that there may be a way to achieve this by accessing the Global Catalog. Is this the correct approach, and if so how is this done using OpenLDAP LDAP api? If this isn't the correct approach, is there a way to query the first VIP server I'm bound to to ask what my Active Directory domain is?
Any help would be appreciated.
you can use system.secutiry principal and name will be returned in domain\usename format the first bit being domain , you dont need to go to AD
mystring= System.Security.Principal.WindowsIdentity.GetCurrent().Name;
I am using LDAP inside Plone running behind Apache on RHEL5 to authenticate users against ActiveDirectory. This worked great until we implemented cross-domain trust. Now the LDAP client doesn't know how to authenticate against the other trusted domains so our other users cannot use the web service.
Is there a nice way for the standard LDAP client to discover the cross-domain trust and try to authenticate against those as well?
Here is the begining of an answer :
It exists objects from the class 'trustedDomain' called Trusted domain objects (TDOs) that represent each trust relationship within a particular domain. Each time a trust is established a unique TDO is created and stored (in the System container) in its domain. Attributes such as a trust transitivity, type, and the reciprocal domain names are represented in a TDO.
If I use 'LDIFDE.EXE' which is an integrated windows server tool like 'ldapsearch' on OpenLDAP to search for such object :
C:\>ldifde -f trustedDomain.lfd -d "cn=system,dc=dom,dc=fr" -r "objectClass=trustedDomain" -l cn
The result is :
dn: CN=mod.dom.fr,CN=System,DC=dom,DC=fr
changetype: add
cn: mod.dom.fr
dn: CN=soc.fr,CN=System,DC=dom,DC=fr
changetype: add
cn: soc.fr
I've got two trusted domains that I can query from the value of the 'CN' attribute of this object.