5:38 p.m.
Hello all,
I have been working with this project for a straight two weeks and i feel lost or stuck.
The goal is to query Windows AD from the linux box located in the DMZ
So, in my virtual lab I have the following:
Windows AD with ip 172.16.5.16 ldap1.gerf02.local
CentOS 6.3 with ip 172.16.5.32 upildap01.gerf02.local
So, my configuration files are as follows:
-*-*-*-*-*-*-*-*-*/etc/openldap/ldap.conf:-*-*-*-*-*-*-*-*-*-*
BASE dc=gerf02,dc=local
URI ldap://172.16.5.16 ldap://172.16.5.16:636
#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
#TLS_CACERTDIR /etc/openldap/certs
TLS_CACERTDIR /etc/pki/tls/certs/stratus_cert.pem
*-*--**-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
*-*-*-*-*-*-**-*-*-*-/etc/sysconfig/ldap-*-*-*-*-*-*-*-*-*-*-*-*-*-*
SLAPD_LDAP=yes
SLAPD_LDAPI=yes
SLAPD_LDAPS=yes
-**-*-**-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-**-*-*-*
-*-*-*-*-*-*-*-*-**-*/etc/openldap/slapd.d/cn=config/olcDatabase={2}bdb.ldif-*-*-*-*-*-*-*-*-*-*-*-***
dn: olcDatabase={2}bdb
objectClass: olcDatabaseConfig
objectClass: olcBdbConfig
olcDatabase: {2}bdb
olcSuffix: dc=gerf02,dc=local
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=Ldap Bind Account,dc=gerf02,dc=local
olcSyncUseSubentry: FALSE
olcMonitoring: TRUE
olcDbDirectory: /var/lib/ldap
olcDbCacheSize: 1000
olcDbCheckpoint: 1024 15
olcDbNoSync: FALSE
olcDbDirtyRead: FALSE
olcDbIDLcacheSize: 0
olcDbIndex: objectClass pres,eq
olcDbIndex: cn pres,eq,sub
olcDbIndex: uid pres,eq,sub
olcDbIndex: uidNumber pres,eq
olcDbIndex: gidNumber pres,eq
olcDbIndex: ou pres,eq,sub
olcDbIndex: loginShell pres,eq
olcDbIndex: mail pres,eq,sub
olcDbIndex: sn pres,eq,sub
olcDbIndex: givenName pres,eq,sub
olcDbIndex: memberUid pres,eq,sub
olcDbIndex: nisMapName pres,eq,sub
olcDbIndex: nisMapEntry pres,eq,sub
olcDbLinearIndex: FALSE
olcDbMode: 0600
olcDbSearchStack: 16
olcDbShmKey: 0
olcDbCacheFree: 1
olcDbDNcacheSize: 0
structuralObjectClass: olcBdbConfig
entryUUID: 0a5111d8-8f04-1031-8728-33c9f43311c7
creatorsName: cn=config
createTimestamp: 20120909195524Z
entryCSN: 20120909195524.946151Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20120909195524Z
olcRootPW: {SSHA}2LzGLoDUm/iPav9Ijm/nLfAtxn9WndvP
olcTLSCertificateFile: /etc/pki/tls/certs/stratus_cert.pem
olcTLSCertificateKeyFile: /etc/pki/tls/certs/stratus_key.pem
-**--**-*-*--*-*-*-**-*-*-*-*--*-*-*-**-*-**-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-***-**
-**-*-*-*-*-*-*-*-**-/etc/openldap/slapd.d/cn=config/olcDatabase={1}monitor.ldif-*-*-*-*-*-*-*-***-*-*
dn: olcDatabase={1}monitor
objectClass: olcDatabaseConfig
olcDatabase: {1}monitor
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=externa
l,cn=auth" read by dn.base="cn=Ldap Bind Account,dc=gerf02,dc=local"
read by * break
olcAddContentAcl: FALSE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig
entryUUID: 0a5108dc-8f04-1031-8727-33c9f43311c7
creatorsName: cn=config
createTimestamp: 20120909195524Z
entryCSN: 20120909195524.946151Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20120909195524Z
-**--**-*-*--*-*-*-**-*-*-*-*--*-*-*-**-*-**-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-***-**-*-*---*-*-**
So, when I execute the following, I get this message
ldapsearch -x -b dc=gerf02,dc=local -D cn=Ldap Bind Account,dc=gerf02,dc=local -W
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext
error, data 52e, v1db1
Thanks for your help,
G
1:35 a.m.
Le 10/09/2012 02:38, GERF a écrit :
Hello all,
I have been working with this project for a straight two weeks and i
feel lost or stuck.
The goal is to query Windows AD from the linux box located in the DMZ
So, in my virtual lab I have the following:
Windows AD with ip 172.16.5.16 ldap1.gerf02.local
CentOS 6.3 with ip 172.16.5.32 upildap01.gerf02.local
So, my configuration files are as follows:
-*-*-*-*-*-*-*-*-*/etc/openldap/ldap.conf:-*-*-*-*-*-*-*-*-*-*
BASE dc=gerf02,dc=local
URI ldap://172.16.5.16 ldap://172.16.5.16:636
The second URL seems invalid,
unless you managed to make your server
reply without SSL on port 636
[..]
So, when I execute the following, I get this message
ldapsearch -x -b dc=gerf02,dc=local -D cn=Ldap Bind
Account,dc=gerf02,dc=local -W
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903A9, comment:
AcceptSecurityContext error, data 52e, v1db1
Which seems to be a valid AD answer.
Did you managed to successfuly
execute the same query against AD directly ?
You should also quote the -D argument value, as it contains spaces...
--
BOFH excuse #367:
Webmasters kidnapped by evil cult.
5:20 a.m.
Guillaume,
You wrote: The second URL seems invalid, unless you managed to make your server reply
without SSL on port 636.
My Answer: So, should I removed it so I can make it reply with SSL ?
You wrote: Which seems to be a valid AD answer. Did you managed to successfully execute
the same query against AD directly ?
My Answer: That answer is unknown user or password. When you say against AD, you mean
using Ldp.exe ? It does reply successfully with simple bind authentication. See Below.
ld = ldap_open("", 389);
Established connection to .
Retrieving base DSA information...
Getting 1 entries:
Dn: (RootDSE)
configurationNamingContext: CN=Configuration,DC=gerf02,DC=local;
currentTime: 9/10/2012 6:14:02 AM Mountain Daylight Time;
defaultNamingContext: DC=gerf02,DC=local;
dnsHostName: DC1SRV2K8.gerf02.local;
domainControllerFunctionality: 4 = ( WIN2008R2 );
domainFunctionality: 2 = ( WIN2003 );
dsServiceName: CN=NTDS
Settings,CN=DC1SRV2K8,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gerf02,DC=local;
forestFunctionality: 2 = ( WIN2003 );
highestCommittedUSN: 408626;
isGlobalCatalogReady: TRUE;
isSynchronized: TRUE;
ldapServiceName: gerf02.local:dc1srv2k8$@GERF02.LOCAL;
namingContexts (5): DC=gerf02,DC=local; CN=Configuration,DC=gerf02,DC=local;
CN=Schema,CN=Configuration,DC=gerf02,DC=local; DC=DomainDnsZones,DC=gerf02,DC=local;
DC=ForestDnsZones,DC=gerf02,DC=local;
rootDomainNamingContext: DC=gerf02,DC=local;
schemaNamingContext: CN=Schema,CN=Configuration,DC=gerf02,DC=local;
serverName:
CN=DC1SRV2K8,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=gerf02,DC=local;
subschemaSubentry: CN=Aggregate,CN=Schema,CN=Configuration,DC=gerf02,DC=local;
supportedCapabilities (5): 1.2.840.113556.1.4.800 = ( ACTIVE_DIRECTORY );
1.2.840.113556.1.4.1670 = ( ACTIVE_DIRECTORY_V51 ); 1.2.840.113556.1.4.1791 = (
ACTIVE_DIRECTORY_LDAP_INTEG ); 1.2.840.113556.1.4.1935 = ( ACTIVE_DIRECTORY_V61 );
1.2.840.113556.1.4.2080;
supportedControl (29): 1.2.840.113556.1.4.319 = ( PAGED_RESULT ); 1.2.840.113556.1.4.801 =
( SD_FLAGS ); 1.2.840.113556.1.4.473 = ( SORT ); 1.2.840.113556.1.4.528 = ( NOTIFICATION
); 1.2.840.113556.1.4.417 = ( SHOW_DELETED ); 1.2.840.113556.1.4.619 = ( LAZY_COMMIT );
1.2.840.113556.1.4.841 = ( DIRSYNC ); 1.2.840.113556.1.4.529 = ( EXTENDED_DN );
1.2.840.113556.1.4.805 = ( TREE_DELETE ); 1.2.840.113556.1.4.521 = ( CROSSDOM_MOVE_TARGET
); 1.2.840.113556.1.4.970 = ( GET_STATS ); 1.2.840.113556.1.4.1338 = ( VERIFY_NAME );
1.2.840.113556.1.4.474 = ( RESP_SORT ); 1.2.840.113556.1.4.1339 = ( DOMAIN_SCOPE );
1.2.840.113556.1.4.1340 = ( SEARCH_OPTIONS ); 1.2.840.113556.1.4.1413 = (
PERMISSIVE_MODIFY ); 2.16.840.1.113730.3.4.9 = ( VLVREQUEST ); 2.16.840.1.113730.3.4.10 =
( VLVRESPONSE ); 1.2.840.113556.1.4.1504 = ( ASQ ); 1.2.840.113556.1.4.1852 = (
QUOTA_CONTROL ); 1.2.840.113556.1.4.802 = ( RANGE_OPTION ); 1.2.840.113556.1.4.1907 = (
SHUTDOWN_NOTIFY );
1.2.840.113556.1.4.1948 = ( RANGE_RETRIEVAL_NOERR ); 1.2.840.113556.1.4.1974 = (
FORCE_UPDATE ); 1.2.840.113556.1.4.1341 = ( RODC_DCPROMO ); 1.2.840.113556.1.4.2026 = (
DN_INPUT ); 1.2.840.113556.1.4.2064 = ( SHOW_RECYCLED ); 1.2.840.113556.1.4.2065 = (
SHOW_DEACTIVATED_LINK ); 1.2.840.113556.1.4.2066 = ( POLICY_HINTS );
supportedLDAPPolicies (14): MaxPoolThreads; MaxDatagramRecv; MaxReceiveBuffer;
InitRecvTimeout; MaxConnections; MaxConnIdleTime; MaxPageSize; MaxQueryDuration;
MaxTempTableSize; MaxResultSetSize; MinResultSets; MaxResultSetsPerConn;
MaxNotificationPerConn; MaxValRange;
supportedLDAPVersion (2): 3; 2;
supportedSASLMechanisms (4): GSSAPI; GSS-SPNEGO; EXTERNAL; DIGEST-MD5;
-----------
res = ldap_simple_bind_s(ld, 'LDAP Bind Account', <unavailable>); // v.3
Authenticated as: 'GERF02\lba'.
But another questions prompts. Why through 389, should not be 636 for a secure connection
?
I am sorry but I am totally new with this. Thanks for your help.
G
________________________________
From: Guillaume Rousse <guillomovitch(a)gmail.com>
To: openldap-technical(a)openldap.org
Sent: Monday, September 10, 2012 2:35 AM
Subject: Re: OpenLdap Proxy with CentOS 6.3
Le 10/09/2012 02:38, GERF a écrit :
Hello all,
I have been working with this project for a straight two weeks and i
feel lost or stuck.
The goal is to query Windows AD from the linux box located in the DMZ
So, in my virtual lab I have the following:
Windows AD with ip 172.16.5.16 ldap1.gerf02.local
CentOS 6.3 with ip 172.16.5.32 upildap01.gerf02.local
So, my configuration files are as follows:
-*-*-*-*-*-*-*-*-*/etc/openldap/ldap.conf:-*-*-*-*-*-*-*-*-*-*
BASE dc=gerf02,dc=local
URI ldap://172.16.5.16 ldap://172.16.5.16:636
The second URL seems invalid,
unless you managed to make your server
reply without SSL on port 636
[..]
So, when I execute the following, I get this message
ldapsearch -x -b dc=gerf02,dc=local -D cn=Ldap Bind
Account,dc=gerf02,dc=local -W
Enter LDAP Password:
ldap_bind: Invalid credentials (49)
additional info: 80090308: LdapErr: DSID-0C0903A9, comment:
AcceptSecurityContext error, data 52e, v1db1
Which seems to be a valid AD answer.
Did you managed to successfuly
execute the same query against AD directly ?
You should also quote the -D argument value, as it contains spaces...
--
BOFH excuse #367:
Webmasters kidnapped by evil cult.
1:29 a.m.
Le 10/09/2012 14:20, GERF a écrit :
Guillaume,
You wrote: The second URL seems invalid, unless you managed to make your
server reply without SSL on port 636.
My Answer: So, should I removed it so I can make it reply with SSL ?
No, using ldap
protocol on port 636 won't work.
And either you need SSL connections by default, and you should use only
an ldaps:// URI, either you don't, and you should use an ldap:// URI.
That doesn't make any sense to use SSL as a fallback if an initial
non-connection failed, which is the sense of multiple values for this
variable.
BTW, this file (/etc/openldap/ldap.conf) just defines default for
openldap libraries, which are only used if the application doesn't
specify one. You'd better use an explicit -H option in your ldapsearch
command, as you do with an explicit -b option.
You wrote: Which seems to be a valid AD answer. Did you managed to
successfully execute the same query against AD directly ?
My Answer: That answer is unknown user or password. When you say against
AD, you mean using Ldp.exe ? It does reply successfully with simple bind
authentication. See Below.
You can use whatever client, as long as you use the same
in both test:
direct connection vs connection through the proxy. You're assuming the
authentication error comes from the proxy, but you don't have any
evidence for it.
--
BOFH excuse #201:
RPC_PMAP_FAILURE
4108
days inactive
4109
days old
openldap-technical@openldap.org
3 comments
2 participants
participants (2)
-
GERF -
Guillaume Rousse